• 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
• how to remove the branches?

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

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)

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