GitFlow is anti-agile
March 9, 2021GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.
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:
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
- 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…
How to experiment with CD in a GitFlow environment
Can we experiment with continuous deployment without completely migrating away from GitFlow first? Here are a couple approaches.
Adventures In DevOps 093: Deconstructing the Minimum Viable Continuous Deployment
The panel jumps in and discusses the Minimum Viable Continuous Deployment from the manifesto on the web and discuss where they agree and disagree with the requirements listed there and clarify some of the ideas in the document.