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 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?”
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 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.”
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.
Top comments (14)
the best git flow I used is mixing rebase and merge on protected branches (master + release branches).it is quite simple:
2 another important points
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:
Hope this gives some more insight!
Git Flow - это проверенная классика и простая концепция. А потом если менять, то уж на GitLab Flow, где применяется усложнение в виде дополнительной стабилизации в pre-prod ветке.
Идея, что в develop ветке лежит самый актуальный код для разработки - очевидная и больше соответствует тем подходам в разработке, которые применяются до какого-либо флоу, что облегчает переход на неё с других CVS (Subversion, TFS), где логика поддержки релизов похожа.
Если начинаете внедрять методологию Git Flow - рекомендую презентацию на русском языке: medium.com/ruopsdev/git-flow-prese...
Там есть ссылки на плагины gitflow для IDE (Visual Studio Code, JetBrains IntelliJ IDEA, Atlassian SourceTree) и сравнение с GitHub Flow и GitLab Flow.
In my view the differences are miniscule, and the importance is communication.
Git is a Communication tool
Jesse Phillips ・ Dec 12 '18 ・ 2 min read
This basically leads to only one type of flow.
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...
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...
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.