Branching model considerations for modern agile organizations

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.

Beautiful branches (source)

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 and value considerations
The models compared
Best practices
Key Metrics
Data from the world to support the above (So we can be data-driven as much as possible)

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:

Collaboration and communication: Individuals and interactions over processes and tools (agile manifesto 2001)
Simplicity: Working software over comprehensive documentation (agile manifesto 2001)
Feedback: Responding to change over following a plan (agile manifesto 2001)
Courage: Psychological safety to feel safe taking risks

Principles

Have a lightweight and clear change process
Aim for trunk-based development as an ideal
Continuous Integration
Continuous delivery (depends on CI and Trunk based development)

The models and practices below are currently the state of the art as far as supporting and acting out these values and principles.

The models

Utopia Model (usually not feasible)

Committing straight to the trunk, good for 1–100 devs

What is it

Basically no branches.
When you are ready to commit — you just commit to the mainline (trunk).

Benefits

The real continuous integration.
Do not need PR cycles.
Can readily deliver small value increments.

Challenges

Need a very comprehensive build.
The full build should be run before each commit and push (and locally).
Increased risk of breaking code for everyone.

The next best thing to the utopia model

Short-lived branches model (SLB), good for 2–1000 devs

What is it

Only one long-running branch
Short Branches (breaking branch-feature 1:1 relationship)
Branches live < 1d
Have to open PR to merge

Benefits

Full build run can be deferred
Lesser risk of breaking the code for everyone
May conduce work alone (also a disadvantage)
No need for code freezes*

Challenges

Need to interrupt some other developer from his flow for PR(context switching)*
Risk putting too much work in one branch*
Forced linearisation of commits may create a bottleneck of PRs
May conduce work alone and developer isolation

*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

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)

Smaller commits

Short-lived branches help with achieving smaller commits.
The larger the changes the longer it takes to review and approve.
Large PR costs:

High context switching cost to the author and reviewers because of back and forth until an agreement is reached
Higher risk of slipping bugs due harder to understand changes
Hurts productivity and lowers throughput

Merge directions

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).

Keep a linear and clean history

Squash when merging PR to main for clear, clean, and easily traversable history

Releases don’t have to be branches

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).

Cherry-pick fixes from main to release branch

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).

Break 1:1 feature-to-branch relationship

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.

Time from PR to approval (hours is good, days bad)
* supporting data in the “data” section below.
Commit rate (the greater the better)
Median time to build (ideally should be less the time between commits)
Overall delivery performance
Lead time: how long from commit to deploy (very dependent on the first three)
Change failure rate: how many deployed changes caused service degradation/failures
MTTR: mean time to restore service

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.