Branching and Merging Link to heading

A Bit of History Link to heading

Git is one of a class of tools that was radically different from all its precursors, powerful, complex, trendy, and that ultimately everyone just decided to not use 99% of (see also Kubernetes). Git was designed to make a very complex distributed asyncronous workflow possible. It’s kind of a poor fit for any kind of enterprise development but it was free and fast. Faster by orders of magnitude than anything before, and so the VCS war was won before it even began.

As is often the case with complex, trendy tools everyone lost their mind and began finding a way to incorporate every possible feature git had into every workflow (see also Kubernetes). And that brings us to Gitflow.

Gitflow Considered Harmful Link to heading

I’m not going to bury the lede here: Gitflow is an anti-pattern. Even the guy who created it has a banner at the top of the original page saying “yeah, you probably don’t want to use this”. Nonetheless, it still shows up in many lists of git branching/merging strategies, usually written by somebody who’s never actually used it.

I’ve personally migrated five different organizations off of Gitflow and on to a better strategy (on which more below). Every single one of them was having all of the problems that Gitflow necessarily creates:

• Long running parallel development branches lead to complex merges and merge conflicts
• The “one branch per deploy environment” design tightly couples your repo to your hosting model
• Slows down releasing significantly and makes continuous delivery impossible
• You’re not deploying what you’re testing because “Dev”, “QA” and “Prod” builds are all done from different source

I’m honestly surprised to see anyone anywhere still recommending Gitflow in 2025. Beware of clickbait and AI slop.

Release Flow: The Better Way Link to heading

I’m sorely tempted to write “…the best way”, there, but I don’t want to be absolutist about anything in this industry. There’s a good summary of the model at releaseflow.org so I won’t repeat it. Release Flow works because it’s simple, elegant, broadly applicable to different development and releasing models, and avoids the problems with more complex branching strategies. It Works, Mate. It turns out that all the power and complexity git offers isn’t actually helping you, it’s a honey trap. Simple is better than complex. I’d even go so far as to say that if Release Flow can’t be made to work with your existing release process, then your release process is flawed and needs re-examining.

But What About… Link to heading

Branching models like Githubflow and Gitlabflow are just variants of Release Flow or Gitflow. As with everything agile, dogmatic adherence to a model some other organization created is getting the cart before the horse. Start with the basic Release Flow model and extend as necessary. Resist the urge to start bikeshedding.

On that note: especially resist the urge to start from the assumption that your particular team, codebase, product, company, market segment or customer demographic is somehow special and therefore none of the usual rules and best practices apply and so you’re just going to have create something new from whole cloth. That’s a honey trap because it makes us feel like we’re very clever people and solving a complex problem for the very first time, when in fact all we’re doing is Reinventing the Square Wheel. The industry has settled on Release Flow as The Right Way To Do It because it is.