War of the Git Flows
Tags: git
Published: 2019-09-10 02:50:41

---
title: War of the Git Flows
published: true
description: 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.
tags: git
cover_image: https://thepracticaldev.s3.amazonaws.com/i/v1423mpc2dgfxsdjnv0i.jpg
---

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

There are many options, including:

* [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/)
* [GitHub Flow](https://guides.github.com/introduction/flow/)
* [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow)
* [Forking Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow)
* [GitLab Flow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html)
* [Trunk-Based Development](https://trunkbaseddevelopment.com/)
* . . . and many more


![GitLab Flow Diagram](https://code.scottshipp.com/wp-content/uploads/2019/08/image.png)<center>_[Image courtesy of GitLab](https://docs.gitlab.com/ee/workflow/img/gitlab_flow.png)_</center>

Companies like Microsoft are even chiming in with their own [Git flow](https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoft).

## The Controversy

The controversy seems to have started with the incendiary 2015 End of Line post, “[GitFlow Considered Harmful](https://www.endoflineblog.com/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 project’s history, I don’t see a reason to ever use GitFlow anymore.

He later authored the aforementioned [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) 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?”

![Two buffalo fighting](https://code.scottshipp.com/wp-content/uploads/2019/08/richard-lee-9ME5tBjVyMQ-unsplash-1024x683.jpg)

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:

![GitFlow branching diagram](https://code.scottshipp.com/wp-content/uploads/2019/08/gitdashflow.png)<center>_[Courtesy of Victor Driessen](https://nvie.com/posts/a-successful-git-branching-model/)_</center>

## 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 don’t care if their developers “rewrite history.” A trunk-based, rebasing workflow like that is shown in this Modern Coder video:

{% youtube f1wnYdLEpgI %}

Others would never think of “rewriting history” and I’m 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](https://www.reddit.com/r/git/comments/2yt9ox/how_do_you_navigate_branch_spaghetti/).”

![Picture of branch spaghetti](https://code.scottshipp.com/wp-content/uploads/2019/08/branch_spaghetti.png)<center>Branch spaghetti as seen in a famous Reddit post</center>

## 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](https://nvie.com/posts/a-successful-git-branching-model/)

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

### [GitHub Flow](https://guides.github.com/introduction/flow/)

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

### [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow)

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

### [GitLab Flow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html)

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](https://trunkbaseddevelopment.com/)

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](https://www.youtube.com/watch?v=f1wnYdLEpgI&feature=youtu.be)

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