Branching Models in a nutshell

Hint: TBD is the best!

I begin by reviewing a few branching strategies I have tried and why I don’t like them so much before going into my favourite, TBD.

Gitflow

• Two main branches that live forever: master and develop.
• Multiple types of rather long lived branches (no defined time about how long these will last, could be days, or weeks — until the feature is finished or bug is fixed). Also Release and Hotfix branches
• Author advises to always merge branches with the — no-ff flag (no fast forward) to preserve the knowledge of the existence of the merge.
• Master branch for tags
• Hot fixing from tags
• It looks like this:

For a more detailed description of Gitflow go here.

Gitflow Issues

• It’s not so good for continuous delivery — Merge conflicts due to long lived feature branches, makes this process a bit waterfallish.
• Advice to not fast forward makes the project history unclean and very hard to read, like this:

Picture credit: https://www.endoflineblog.com/gitflow-considered-harmful

• The master/develop split is redundant, there is no clear advantage of having a master branch when you can tag just as well off the develop branch for your milestones.
• There can be feature discrepancies as they are long lived.
• Unpredictable releases because of how long the feature may take to develop, it could take a while before it gets to production.
• Pointlessly complex, easy for new developers to get very confused by this and mess things up.

For a more extensive criticism of Gitflow go here.

Gitlab Flow

• Gitlab uses multiple, infinitely lived branches, each of them per environment, code trickles down like so:

• In this model you create a feature branch which is short lived and merged often to master. Ideally these features are code reviewed before going into master, then this master branch can travel its way down towards the production environment.
• Everyone starts from master and targets master, other branches are merged from previous lower environment branches.
• Convenient method with gitlab CI/CD method.
• If you want to know more about Gitlab flow go here.

Gitlab Flow Issues

• Having multiple long-lived branches can easily create spaghetti merges and out of order commits, especially if some had to merge from a higher to a lower environment.
• If these branches start being different and you have to do lots of non fast forward merges then you are going to end up with a very messy history.

Github Flow and Other Branching Models

The above branching models are the ones I have the most experience with and the only ones I will be covering in this article, other branching models, including the popular github flow are covered here

Trunk Based Development (TBD)

• Master becomes a protected branch where you can only merge to but not push to.
• All merges get tested and reviewed.
• Master (the trunk) deploys to an environment where it is thoroughly tested against every possible component, if it fails, it gets repaired within 10 minutes:

• Features or fixes are implemented in short lived branches that are also tested. These branches are merged once a day after tests pass. If a feature is not finished it gets turned off with feature toggles before merging back to the main branch to be picked up again later.
• Using feature toggles you can keep merging to the main trunk without breaking it because the feature can be disabled if it’s not finished. Another advantage of this is that you can enable A/B testing, turning on the feature for some users and not others.
• When merging a feature to trunk you squash the commits on the feature branch and keep the message as descriptive as possible, of the work you have done. This is to avoid messy histories that show all of the tiny little changes in the feature or fix branches before merging.
• Whenever deploying to production you can create an annotated tag semver style vx.x.x and this can be deployed to production by an authorised party. Some people prefer to have release branches for this, but I personally don’t see a lot of advantage to doing that, doing in per tag feels cleaner.
• Hotfixing is discouraged with this method, the traditional concern when doing hotfixes is that there may be features unfinished that are not desired in production. However this is mitigated by the fact that production releases are done daily from a trunk that’s always in deployable state, so there shouldn’t be a large discrepancy between what’s on trunk to what’s on production for it to warrant hotfixing, simply fix it on trunk and deploy the new tag to prod.
• However if hotfixing must absolutely be done for any particular reason, the best procedure is to fix the issue in the trunk and then create a hotfix branch from the affected production tag, cherry pick the change from trunk in there and then release that to production with a new hot fix tag — remove the hotfix branch when you are done.

Advantages of TBD

• Increased deployment frequency
• It goes hand in hand with CI/CD
• The history and versioning remains clean and it’s easy to go back in time and revert a deploy. No more confusion with multiple long lived branches.
• Fewer merge conflicts or spaghetti branching.
• Commits in trunk are far more meaningful (especially if you squash your short lived branches before merging) and they represent working states.
• This is the road to releasing to production daily, as soon as a change, feature or fix is ready and working you release to prod. Rather than releasing a bunch of features and changes at once, it’s much easier to spot the issues with your deployments this way and fix them.

Disadvantages of TBD

• It requires discipline from your developers and a good understanding git and feature flags. Although if you are not comfortable with feature flags yet it’s not a deal breaker, you could always rebase your short lived branch against master daily and sort out conflicts before finally merging your feature if you need more than a day to complete it.
• Plenty of automated testing is a requirement with this method, the good thing is that starting out this way, your developers are more likely to get into the habit of testing their code.

Additional information

https://trunkbaseddevelopment.com

Conclusion

It is quite obvious I have a predilection for TBD, mainly because it’s clean, orderly and easy to understand, it may require more discipline but the results speak for themselves if done well.

TBD is not new, untested and revolutionary and it has been recommended as the preferred method right from the start of the DevOps movement

These are however not rules, in the world of tech no solution applies to all cases and what may work for most, may not work for you. So if any other branching model is better for you or you need to make some modifications to it, then go ahead, but at the very least is good to be aware of all the options before making a decision of what to pick for yourself.