Who cares if we use GitFlow?

GitFlow vs Trunk-Based Development is like Coke vs. Pepsi, right? Not really.

Who cares if you use GitFlow?

Someone always asks this question whenever the topic of GitFlow versus alternatives comes up.

It’s a reasonable enough question. It sounds a lot like Coke vs Pepsi, tabs vs spaces, Emacs vs vi, or Ruby vs Python.

Pick a tool or technique that works for you, and use it. Right?

Seems pretty reasonable.

And I would agree, if that’s as far as it went. And in fact, if you never change anything else at all about your workflow other than your branching model, then yeah, it’s a pretty isolated choice. Use one that works for you.

But here’s the thing. GitFlow isn’t just a branching model. Or more precisely, it has a ripple effect that influences all sorts of behaviors in your software development and delivery.

To get specific, GitFlow makes continuous integration impossible. Which in turn makes continuous delivery and continuous deployment impossible.

Now, if you never intend to use continuous integration, continuous delivery, or continuous deployment… then sure. By all means, use GitFlow, if for some reason you enjoy the extra steps and merge conflicts it gives you.

If that’s not your idea of a good time, though, and you need some help escaping the GitFlow trap, my free 10-day email Lean CD bootcamp may be able to help.