There is a lot of discussion going on about branching strategies and how a good branching strategy looks like.
My preferred branching strategy has only 2 rules:
- Rule #1 – Don’t branch
- Rule #2 – Go read Rule #1
Branching should be an exceptional case as every branch introduces a merge cost (and this cost can be high!). Of course in reality, it’s not always that simple.
With the renewed vibe around Continuous Integration and DevOps, a good branching strategy is crucial. One blog series I recommend reading is Version Control Strategies:
This series of articles describes a taxonomy for different types of Feature Branching – developers working on branches in isolation from trunk – and how Continuous Integration is impacted by Feature Branching variants.
- Organisation Antipattern: Release Feature Branching – the what, why, and how of long-lived feature branches
- Organisation Pattern: Trunk Based Development – the what, why, and how of trunk development
- Organisation Antipattern: Integration Feature Branching – the what, why, and how of long-lived integration branches
- Organisation Antipattern: Build Feature Branching – the what, why, and how of short-lived feature branches