Source code branching can provide great advantages such as isolating features, allowing multiple developers to avoid stepping on each others toes, and even allowing for focused testing. Branching can also introduce overhead and complexity with merging, conflicts and even managing the scope of releases. I reached out to our experts to get their thoughts on branching:
In my experience, the branching strategy you (should) use is largely dictated by the project, the number of people working on it, and your ability to continuously deliver. If you’ve got a single developer who is able to immediately release everything, a single master branch that may or may not just be upstreamed feature work you’ve completed is plenty. If you have more than two or three developers actively working in the same code base, spinning your work off into a series of feature branches that are able to be independently code reviewed prior to merging back becomes necessary. The other struggle is your ability to deliver. If your work isn’t something that you can just immediately release, or maybe you’re cherry-picking completed features, having a separate release branch that you merge to becomes necessary.
TL;DR | As simple as possible to avoid confusion, but more complex as your situation gets more complex.
I prefer to avoid bloated branching strategies. There are definitely situations where having a layer or two of security between your production code and volatile development branches is important. In most cases though, I prefer at most three branches away from the master branch. One aggregate development branch, one for each feature in development, and child to those feature branches, one branch for each code addition that adds value.
I prefer to use the common GitHub branch strategy, where feature branches get merged into master via pull request and peer review. At any point in time master can be branched as a “release”. I have followed other branching strategies, but none of them seem as simple. This branching strategy seems to answer all the questions you should ask yourself when deciding on a branching strategy for your project. This GitHub branch strategy has served me (and literally 20 million other users) well for years!
I steer towards single-trunk/trunk-only/no-branches. Keeping everyone’s work in the same place makes merges tiny, and avoids all questions like:
This doesn’t come easily – it requires additional discipline and development techniques. Extensive feature toggling is necessary to avoid releasing partially finished work, which requires a well-fragmented architecture. Note that partially finished code might ride along to production – it’s just not exposed or run. Heavy automated testing is also needed to catch issues as soon as they appear. Small, frequent check-ins keep integration and merging issues lightweight and easy. This is a major shift from most teams’ processes, but the rewards can be great.