This page describes the branching model we want to apply for development at Magnolia.
The model
The model is basically the same as described in a blog post.
Differences
- We'll not use hotfix branches
- We'll use the term development branch instead of integration branch
VCS (git)
Development branch
- Will have a proper hudson job
- Will have a proper pom-version (e.g.. x.y.z-DEV-SNAPSHOT)
- Rule: revert immediately as soon as it fails
Master
- Scrum masters merge at the end of the sprint (develop -> master)
- BEWARE to not merge back the "DEV" in the pom version!
Feature branches
- on central repo? ( see open issues)
- remove them after the final merge
- list of feature branches
- --> things we are actively working on or are waiting
Maintenance
- no changes
- no hot fix branches (for the moment)
Open Issues
Merging params to use
We should decide to consistently use
- git merge --squash when merging from feature branch to develop
- one consolidated commit with meaningful message for a feature
- or use git merge --no-ff instead
- no fastforward - avoids losing information about the historical existence of a feature branch + groups together all commits of a feature
Not using one of the above will result in situations where it might be very hard to figure out what commit's belong together (e.g. really bad if u have to revert a feature)
Sharing feature branches [Daniel]
- How to share: options
- ppl could define remote repos on others computers
- potentional spider net: over time every dev could work with every other...
- no out-of-the-box backup
- hard to track what's being worked on (if not merging frequently from and to dev)
- use central repo
- always backup
- easy to track what's being worked on
- dev's need permission to remove branches
- ppl could define remote repos on others computers
Version conflicts for snapshots [Daniel/Gregory]
- No known automated process to guarantee that not the wrong versions are used on the master!
Continuous integration
- to have a chance to reveal conflicts pretty soon we have to
- frequently (daily?) merge from development to feature-branch (to get in stuff from other devs)
- frequently (daily?) merge back from feature-branch to development branch
- Difference to directly working on development branch
- less blocking of others
- easier to wipe not-working stuff without leaving traces
- can easily squash commits related to one feature
- frequent merging (dev-feature, feature -> dev)
Q: if we're merging to development branch on a daily base, shouldn't the feature branches then rather be local?
QA
- when should the review take place?
- before merging from feature branch to development
- or before merging from development to master
Branching effort
Creating branches and merging is cheap in git - but if you have to touch lot's of modules it might no longer be the case
- As we almost have a one git-repo per module setup feature branching might involve quite an effort in maintaining branches
- e.g. for metadata-as-mixin we have to create (later merge then delete) branches for magnolia_main, magnolia_ui, ce-bundle, stk?, etk?, demo-project?,...
Links
By the way: feature branching vs. continuous integration has heavily been debated - mainly because of Martin Fowler's vote to not go for feature branches. Here's a bunch of links around it:
- a successful git branching model (main influence for our approach)
- a tidy git workflow (similar to above)
- continues delivery (Martin Fowler et al. voting to not go for feature branches)
- minutes from our first meeting