Agile Version Control

The goal is to enable you to be more agile, i.e., to improve your ability to change and adjust.

Here’s what I think:

• Goals: rapid feedback, fail fast, always releasable, simple (i.e., easy to use)
• Visibility is important here, too: Everyone can see what’s happening

Mainline and CI

• There should be a mainline – Everyone Commits To the Mainline Every Day
• IMO, the mainline – i.e., what you are working on every day – should be ready to release from at almost any time. This implies low technical debt, and little difference between mainline and a release branch (if you use that) – i.e., less work in progress at any time.
• Maybe a release branch is a good idea – where you actually can release from at any time

• Beware of feature branches, and kill them as soon as you can if you do use them. (One tip: feature toggle)
• Branches: Merge from mainline every day if you have them.
• Good naming goes for build code and infrastructure, too, so I’d prefer branch names like mainline, release, featureA, fixB
• Limit branches agressively – they represent more work in progress (and you want less work in progress) including risk of big merges

• 

  Merging: merge down, copy up – always accept stabilizing changes, never impose destabilizing changes.

Inspiration:

Martin Fowler: articles on continuous integration

Henrik Kniberg: Agile version control with multiple teams