GitFlow is anti-agile

March 9, 2021

If you don’t know what GitFlow is, you can stop reading now, and consider yourself better for it.

If you do know what GitFlow is, it’s likely because your current team, or a past one, has used it as a way to control software delivery. At a high level, GitFlow looks like this:

GitFlow illustrated

Clear as mud, right?

This process is fraught with problems. Here are a few:

  • It’s confusing.
  • It’s a waterfall process. Code moves from development to testing to release, in clearly defined stages.
  • It duplicates work. Every code change must be merged at least twice. Three times for any point-releases or hotfixes.
  • It makes continuous integration impossible, due to the multiple integration points (see the point immediately above)
  • It makes continuous deployment impossible, since code is manually moved from develop to master
  • It is error prone. It’s very easy for one of the requisite merges to be accidentally missed. I’ve seen this exact failure recently at a well-known and respected international open-source company, leading to regression failures across major releases.

Fortunately, to his credit, even the creator of GitFlow, Vincent Driessen, has recognized that his process does not work well with modern agile software delivery. In March of 2020, he added a preamble to his post stating, in part:

[T]he most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow instead of trying to shoehorn git-flow into your team.

Although he still advocates GitFlow for projects that “need to support multiple versions of your software in the wild”. I think this is also wrong. I don’t know of any circumstance where GitFlow is an appropriate tool, simply because there are lighter-weight alternatives. But more on that another day…

Related Content

There's no reason not to use a linter

Simply adding a linter to your build pipeline is usually the simplest, cheapest single step you can do to improve code quality.

A merge a day keeps the conflicts away

Merge a minimum of one PR each day. Make small PRs. Don't worry if the feature is incomplete, only that each PR works.

The U-Shaped Cell

The Toyota Production System's U-Shaped Cell is a favorite DevOps analogy: Put all the tools within reach of a single developer.