loading...
Cover image for War of the Git Flows

War of the Git Flows

scottshipp profile image scottshipp ・3 min read

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

There are many options, including:

GitLab Flow Diagram

Image courtesy of GitLab

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 project’s history, I don’t 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?”

Two buffalo fighting

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

Courtesy of Victor Driessen

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:

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.”

Picture of branch spaghetti

Branch spaghetti as seen in a famous Reddit post

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.

Posted on by:

scottshipp profile

scottshipp

@scottshipp

AWS, Spring Boot, Core Java, and backend developer.

Discussion

markdown guide
 

the best git flow I used is mixing rebase and merge on protected branches (master + release branches).it is quite simple:

  1. you update your branch using rebase pull is defaulted to rebase and to update your branch from another branch you rebase it.
  2. to deliver your work you merge (--no-ff) your branch to the corresponding protected branch after you rebased it from the target branch. I implemented this flow in my company and it is prefect for us. it allow you to have a clean and readable history with trace of deliveries (start of branch and it's delivery) that standard rebasing flow doesn't allow. after I rolled it out in the company I discovered that the only got server allowing to enforce this flow is gitlab. they called it semi linear history. after that I discovered that I am not the only one to use it. look at it for more details: fangpenlin.com/posts/2013/09/30/ke...
 

2 another important points

  1. when you take update via rebase and merge to incorporate you changes is that you are always playing your changes onto others branches and never incorporate others changes into yours (default pull using merge or merge from master or release branches onto yours to update it)
  2. merging to deliver using --no-ff ensure you can follow the delivered work on master (or any release branch) using log --first-parent and prevent parent inversion because of fast forwards...
 

btw in the link I provided they suggest to push -f to update your remote branch after rebasing. I think that --force-with-lease is safer (in 2013 the option wasn't available)

 

This also sounds like what we do at my company

 

Totally agree - there are tradeoffs with each, and it's really up to you and your team to figure out what is best for your codebase.

Also: I didn't realize there were so many named git worksflows! 🤣 Thanks for the roundup - I have some reading to do on some of those :)

 

At my previous job, we had this discussion as well, and the chosen branching model was Release Flow, as used by Microsoft. It has release branches and feature branches, optionally uses rebasing, and no merges. Main distinguishing feature is that hotfixes are committed to master and then elevated/cherry picked to the feature branch.

Our reasoning was as follows:

  • We still wanted release branches, as they can provide extra stability (for example performing extra tests manually). This could later be changed to better suit continuous integration, but stability was an important factor.
  • We want to enforce that a fix that lands in a release branch also lands in any following release branches (it had happened before that a release branch containing a hotfix wasn't merged back into master, as can possible happen with flows like Trunk Based Development and OneFlow).

Hope this gives some more insight!

 

My senior collegue :
Git/Hg flow is the worst, but if not flow then what?!
We brainstormed, gave a bunch of other "flows" and came to the conclusion that git/hg flow is indeed the worst, and we still are gonna use it...

 

In my view the differences are miniscule, and the importance is communication.

This basically leads to only one type of flow.

  • branch off a branch
  • take update via rebase
  • merge request to incorporate changes

The specifics about release and patching comes from a need to update a specific commit. That specific commit can be tracked in many ways.

 

I don't think I'm following: "the differences are miniscule" but when "the importance is communication" it "leads to only one type of flow." The flow you suggest is completely different from several of the listed flows, so they don't seem to be "miniscule" differences and it seems like teams have settled on completely alternate approaches in their attempt to communicate. Help me understand what I'm missing.

 

(sorry more ramblings) If you don't rebase your working/feature branch, you don't care about communication (or your development is much more organized then mine).

If you stand up long standing branches, you must have large contribution teams with frequent support for your various releases, otherwise you're solving for a problem you don't have.

In the article it states that git flow doesn't use rebase, if you do no buddy will know. This thought that you can force someone to not do rebase is rediculous, but you can clearly enforce needing to rebase.

I was once on the camp that it didn't matter, rebase or merge, git will figure it out and combine changes. But I ended up in quality assurance and being able to clearly define what is change and why for each line of code is critical to a good review and understanding.

I take shortcuts, but if quality really is important, better orginizing or even eliminating the last 25 commits is worth it.

quoteinvestigator.com/2012/04/28/s...

 

Thanks for the very comprehensive list! I didn't know there were this many!

 

I dont have any experience with git flow. I have plan to use it but need more knowledge before implement to my repository. Your article give me new information that there are some git flow.