Announcing Coherence 2.0 and CNC, the first open source IaC framework
All posts

A more successful git branching model

In the ever-evolving software development landscape, one of the most influential ideas of the past decade has been the "git flow" working style, thanks to the iconic blog post "A Successful Git Branching Model." Here, we suggest an updated workflow with less long-lived branching.
January 30, 2024

In the software development world, one of the most iconic blog posts of the last decade is “A Successful Git Branching Model” (https://nvie.com/posts/a-successful-git-branching-model/). It popularized “git flow”; a working style that uses a combination of long and short lived branches to move code from development to production. Coming on the heels of Heroku’s beloved “git push” deployment experience, the web software world quickly adopted this idea, and if you’ve worked in SaaS recently, you likely have a dev, staging, and production branch alongside your trunk branch.

For many, this workflow has been a godsend, yet for engineers experienced on the ground, it comes with familiar challenges. Reverting a merge commit on a long-lived branch often leads to conflicts in git histories for those who have already merged it. Cherry-picking commits between branches is another tedious and intricate task. As is testing changes in development or staging environments before integrating them. Additionally, waiting in a merge queue to test fully integrated changes is a frequent, time-consuming bottleneck.

GitHub observed these pain points and introduced the “github flow” (https://docs.github.com/en/get-started/quickstart/github-flow) model — which works for simpler SDLCs, greenfield projects, and other cases. The core idea here is to have only one long-lived branch. You can test feature branches locally, or you can add a workflow on top for using other testing environments. This can work great without a lot of additional environments or tools on a small team. But it might not match 1-1 the old SDLC that a team uses today, or the environments they work in and how they promote between them if they are tied to long-lived branches. If not, adopting this workflow is a tough sell for teams that have invested in compliance and docs/training around using longer-lived environments. 

We designed Coherence to directly address these pain points. Branch-based short-lived preview environments are helping teams test and collaborate with better production parity faster. But we don’t see long-lived environments like staging, demo, UAT, and QA going away either. Teams need the ability to protect trunk branches using source control settings like protected branches, required reviews, and automatic test configurations. They also need role-based access control for managing team deployment permissions. Coherence offers a great user experience for both long-lived and ephemeral environments, effectively solving the pain points of git flow while keeping your pre-production review and testing workflow intact as new capabilities are introduced.

The more successful git branching model looks like this:

Teams that use this workflow are able to get a great developer experience and often see a 10x ROI very quickly. You can move from git flow to something more like github flow without losing all your staging and other environments and how they work together to help you deliver a great product to your users. We’d be excited to show you what we can deliver for your team - get in touch today