GitFlow is anti-agileGitFlow 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…
Who cares if we use GitFlow?
GitFlow vs Trunk-Based Development is like Coke vs. Pepsi, right? Not really.
Implementing Continuous Delivery in Reverse - ATVIE22
If you heard about Continuous Delivery you might find it sounds great, but you are not ready for it because [insert excuse here].