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.

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.

1. Time from PR to approval (hours is good, days bad)
   * supporting data in the “data” section below.
2. Commit rate (the greater the better)
3. Median time to build (ideally should be less the time between commits)
4. Overall delivery performance
5. Lead time: how long from commit to deploy (very dependent on the first three)
6. Change failure rate: how many deployed changes caused service degradation/failures
7. 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.

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)

• 80% are single file changes (over 10% are single-line changes)
• The median time to get code reviewed is 4 hours
• Median dev authors 3 changes a week
• The median changes reviewed per week is 4 (by a dev)

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.

Delivery Performance

State of DevOps reports shows year over year that the highest performing teams:

• Deploy the most frequently
• Have the lowest lead time for changes (from code committed to production)
• The quickest to restore service in case of failure
• Fail less often (% of changes deployed that are bad)

To the brave soul who reached this point, I’m proud of you.

Comments, thoughts, data, and experiences are welcome in the comments below.