Stuck on choosing a Git branching model? This article will help you decide.
It’s always the same story. I join a new project with a new team, excited about what we are about to create together. Software making is a team sport so, together is a key-word here. We brainstorm together, and design together. But, unfortunately, most of the time we code alone. Like always we quickly remember that all our code has to be then merged somehow, and so the history repeats itself. We are choosing a branching model — again.
If your team also facing the dilemma of choosing a branching model, keep reading. In this article, I compiled a lot of thinking points, facts, and perspectives that will allow you to elevate these discussions with your team way beyond the “this is how we did it in my previous team” level.
We are choosing a branching model, again
For convenience, I’ve divided this into sections:
Culture values and principles
As DevOps is one of the byproducts of Agile, it’s heavily dependent on culture.
Since the inception of Agile it always prioritized the following values:
Utopia Model (usually not feasible)
Committing straight to the trunk, good for 1–100 devs
Basically no branches.
When you are ready to commit — you just commit to the mainline (trunk).
The next best thing to the utopia model
Short-lived branches model (SLB), good for 2–1000 devs
*look at solutions in the ‘best practices’ below
Modern Best Practices
Use these to help alleviate the above challenges (actual success depends on the culture).
Pair programming is basically an online code review.
Eliminates costly context-switching. Pair programmed PR is essentially already auto-approved (to the point that PRs can be automated)
Short-lived branches help with achieving smaller commits.
The larger the changes the longer it takes to review and approve.
Large PR costs:
Rebase to bring your branch up-to-date before opening a PR.
This helps to keep your branch — about your changes (contrary to merge that mixes all together).
Squash when merging PR to main for clear, clean, and easily traversable history
Release may be cut from Tag on main.
For fixing an issue in production, a release branch can be created retroactively from the Tag (and cherry-picked from main).
This will eliminate the need to do code freezes.
No need for error-prone multi-branch merges (as in git-flow).
Will keep the history readable, clean, and clear (and auditable).
A feature is not a branch. If you are using Jira or similar and used to name branches after tasks, try to stop tying branch and ticket life-cycle. Many small and short-lived branches are OK.
KPIs and Metrics
A shortlist of things to measure will allow you to get a feel for developer experience and spot dev velocity bottlenecks.
Interesting Data that we see in the world
A sociologist Ron Westrum created a culture model where he defines the following typology of organizations (Westrum 2014). He found that this definition of organizational culture predicts performance outcomes.
A two-year google study found similar results (https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/)
Statistics about code review from “A modern code review: A case study at Google” (2018)
How understanding needs to change with the expected outcome of code review
Delivery performance capabilities map (State of DevOps report 2019)
When it comes to commits — smaller is better.
State of DevOps reports shows year over year that the highest performing teams:
To the brave soul who reached this point, I’m proud of you.
Comments, thoughts, data, and experiences are welcome in the comments below.