War of the Git Flows

A battle is raging among software engineers around the world: which Git flow should our team use?

There are many options, including:

• GitFlow
• GitHub Flow
• OneFlow
• Forking Workflow
• GitLab Flow
• Trunk-Based Development
• . . . and many more

Companies like Microsoft are even chiming in with their own Git flow.

The Controversy

The controversy seems to have started with the incendiary 2015 End of Line post, GitFlow Considered Harmful. In this post, an Amazon developer named Adam Ruka griped:

[I] believe that GitFlow is fundamentally flawed in many aspects, and my experiences of observing people trying to apply it only confirm that impression. And because there is a simpler, equally (or, I would even argue, more) expressive way to manage your projects history, I dont see a reason to ever use GitFlow anymore.

He later authored the aforementioned OneFlow which may or may not have muddied the waters even further. OneFlow unfortunately contains many optional components that I would argue change the result quite significantly. For example, a team squashing and rebasing is quite different from a team doing neither. Is it really one flow?

Regardless, GitFlow has definitely been chided by others. Consider the normally neutral GitLab documentation. It calls Git Flow annoying, full of ceremony, and too complicated.

Vincent Driessen, the author of the blog proposing GitFlow, offered this chart to help illustrate the method, but it has often been used as evidence of GitFlow being an overwrought process:

Are the alternatives better?

Everyone seems to want something different out of their Git flow. One team wants a very clean, linear commit log. They dont care if their developers rewrite history. A trunk-based, rebasing workflow like that is shown in this Modern Coder video:

Others would never think of rewriting history and Im sure there are some who would throw tomatoes at The Modern Coder if they could.

Some teams commit often and add merge commits on top of that. Their git repositories look like tree roots snaking back and forth across each other, so-called branch spaghetti.

Pick your poison?

So is it merely a case of pick your poison?

You decide. Here is a list of flows and their characteristics to help you decide what will work best for your team, or to help you customize to your own new flow.

GitFlow

Uses feature/topic branches: Yes.
Uses release branches: Yes.
Uses rebasing: No.
Merges: No fast forward merges.

GitHub Flow

Uses feature/topic branches: Yes.
Uses release branches: No.
Uses rebasing: No.
Merges: Unclear merging strategy.

OneFlow

Uses feature/topic branches: Yes.
Uses release branches: Yes.
Uses rebasing: Optional.
Merges: Up to you.
Other: Uses hotfix branches.

GitLab Flow

Uses feature/topic branches: Yes.
Uses release branches: Yes.
Uses rebasing: Optional.
Merges: Up to you.
Other: Integrates with issue-tracking. Use of environment branches.

Trunk-Based Development

Uses feature/topic branches: Optionally, if short lived.
Uses release branches: Yes.
Uses rebasing: Optional.
Merges: Optionally, if using short-lived feature branches.
Other: None.

Rebasing Flow

Uses feature/topic branches: No.
Uses release branches: Optionally.
Uses rebasing: Yes.
Merges: No.
Other: unclear how code reviews happen.