149

We have recently started to use GitLab.

Currently using a "centralized" workflow.

We are considering moving to the github-flow but I want to make sure.

What are the pros and cons of git-flow vs github-flow?

random
  • 9,774
  • 10
  • 66
  • 83
Paul McKenzie
  • 19,646
  • 25
  • 76
  • 120

3 Answers3

145

As discussed in GitMinutes episode 17, by Nicholas Zakas in his article on "GitHub workflows inside of a company":

Git-flow is a process for managing changes in Git that was created by Vincent Driessen and accompanied by some Git extensions for managing that flow.
The general idea behind git-flow is to have several separate branches that always exist, each for a different purpose: master, develop, feature, release, and hotfix.
The process of feature or bug development flows from one branch into another before it’s finally released.

Some of the respondents indicated that they use git-flow in general.
Some started out with git-flow and moved away from it.

The primary reason for moving away is that the git-flow process is hard to deal with in a continuous (or near-continuous) deployment model.
The general feeling is that git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more.

In short:

Start with a model as simple as possible (like GitHub flow tends to be), and move towards a more complex model if you need to.

You can see an interesting illustration of a simple workflow, based on GitHub-Flow at:
"A simple git branching model", with the main elements being:

  1. master must always be deployable.
  2. all changes made through feature branches (pull-request + merge)
  3. rebase to avoid/resolve conflicts; merge in to master

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f772d32303133303932362d3139333431392e706e67

For an actual more complete and robust workflow, see gitworkflow (one word).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 3
    rebase to avoid conflicts??? – stopsopa Mar 01 '21 at 14:48
  • 1
    @stopsopa It means to resolve conflict locally (during the rebase) in order for the merge to be a trivial fast-forward one. – VonC Mar 01 '21 at 14:50
  • In the simple git branching model link in the sample I do not understand the git rebase origin/my-new-feature line. Regarding the prev lines, is not it moves the main branch to the tip of the my-new-feature branch, which is definitely a nodo, I mean rebasing a public branch? – g.pickardou Sep 18 '21 at 05:14
  • @g.pickardou It does not move the main branch, considering there was a `git checkout -b my-new-feature` first. But it is not needed either. Rebasing a public branch like `master`/`main` would be a no-no indeed. – VonC Sep 18 '21 at 16:14
  • Thx, it seems I must do my homework in the very next future on this topic – g.pickardou Sep 19 '21 at 05:44
  • @g.pickardou these days, I really prefer gitworkflow: https://stackoverflow.com/a/56555040/6309 – VonC Sep 19 '21 at 14:01
109

There is no silver bullet workflow where everyone should follow, since all models are sub-optimal. Having said that, you can select the suitable model for your software based on below points;

Multiple versions in production - use Git-flow

If your code is having multiple versions in production (i.e. typical software products like Operating Systems, Office Packages, Custom applications, etc) you may use git-flow. Main reason is that you need to continuously support previous versions in production while developing the next version.

Single version in production simple software - use Github-flow

If your code is having only one version in production at all times (i.e. web sites, web services, etc) you may use github-flow. Main reason is that you don't need to complex things for the developer. Once developer finish a feature or finish a bugfix its immediately promoted to production version.

Single Version in production but very complex software - use Gitlab-flow

Large software like Facebook and Gmail, you may need to introduce deployment branches between your branch and master branch where CI/CD > tools could run, before it gets in to production. Idea is to introduce more protection to production version since its used by millions of people.

Gayan Pathirage
  • 1,979
  • 1
  • 24
  • 21
  • 7
    Just adding "Gitdmz-flow" / "Git DMZ Flow" to the list: https://gist.github.com/djspiewak/9f2f91085607a4859a66 – Robert Fey Apr 29 '16 at 17:41
  • 1
    The companies referenced use a trunk based system. http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/ – PatrickWalker Oct 14 '16 at 22:06
  • 2
    Git DMZ flow is more similar to Gitflow and DMZ branch is like develop branch. Hence I feel nothing special about it. – Gayan Pathirage Feb 24 '17 at 06:11
  • Trunk (aka Cactus) based development is coming from a non-git world where branching and merging are costly. (e.g. Google on Perforce while Facebook on Mercurial according to Paul Hammant). Cactus like branching is good when you have the correct set of automated tools in place to secure the trunk in CI/CD. Needless to say, Google and Facebook is having that infrastructure. The question is do you have? or more specifically do you know what you should have? – Gayan Pathirage Feb 24 '17 at 06:21
  • 2
    From my understanding, Git-Flow does not works well with multiple-production version. The hotfix strategy assume you only have one production version, and you do hotfix on the corresponding release branch (and later merge it back to develop branch). It seems do not cater how you can fix one bug that exist in multiple production branch. – Adrian Shum Nov 20 '17 at 06:21
  • @AdrianShum if you keep the active release branches, you can simply fix such a bug/add a missing feature at the oldest active release and merge it for all subsequent releases and provide an update to clients on respective paths. Which we do in practice. (NOTE: GitFlow specifically ask to create hotfix branch from a tag in master, which is technically same as creating the same from the end of the relevant release branch) – Gayan Pathirage Nov 28 '17 at 11:10
  • 7
    @GayanPathirage Actually it is not. 1. "classic" GitFlow tags at master. Hotfix branch is only for you to do a fix against the latest production version (from master). 2. "release branch" means something else in Gitflow, which is actually the pre-release preview branch (branching from develop branch, and aimed to merge to master when it is really released). 3. What you are referring is something called "support branch" in GitFlow (That's one reason I dislike GitFlow: unconventional terminology). However it is still experimental flow (so you don't see it in most of the Gitflow Intros) – Adrian Shum Nov 29 '17 at 06:23
  • Git DMZ Flow: _This is fundamentally where the Git DMZ Flow separates itself from GitFlow. In GitFlow, you have a shared develop branch that anyone can push to. Work is done in feature branches by convention, but ultimately anyone can just drop code into develop. Now, it is understood in the workflow that develop is sort of unstable for precisely this reason, and this is why develop is separated from the deployable master. But that doesn't prevent other developers from being hindered by the instability of develop, since everyone is cutting their feature branches from develop, not from master!_ – klaar May 04 '18 at 12:36
  • NOT the same as Gitflow: _With the Git DMZ Flow, all branches are always cut from master, which is just as pristine as master in GitFlow. Work flows efficiently from feature branches back into master, via the pull request process, but the automated guarantees ensure that this efficiency does not come at the expense of stability. Thus, the Git DMZ Flow does not require a separated develop branch; master is develop, but in a perfectly stable form! This makes the process both lighter-weight, less prone to blockage (no build failures, ever) and more streamlined in terms of branch maintenance._ – klaar May 04 '18 at 12:37
  • With this post I understood that most people use a "juiced version" of the "Git Flow" model and not the original one: You keep the old release branches so that you can overcome the "multiple version maintenance" problem. Interesting! – Luis Gouveia Oct 31 '19 at 15:32
44

I've been using git-flow model for over a year and its ok.

But it really depends on how how your application will be developed and deployed.

It works well when you have an application that have a slow development/deployment flow.

But for example, like GitHub we have an application that has a fast development/deployment flow, we deploy everyday, and sometimes several times a day, in this case, git-flow tends to slow down everything in my opinion, and I use GitHub flow.

The other thing to consider is, git-flow is not standard git, so you might, and when I say you might, I really mean, you will find developers that don't know it, and then there is the learning curve, more chance to mess things up. Also as mentioned above, someone developed a set of scripts to make the use of git-flow more easy, so you don't have to remember all the commands, it will assist you with the commands, but remembering the actual flow is your job, I've came across more than once when a developer didn't know whether it was a hotfix or feature, or even worst when they can't remember the flow and stuff things up.

There is at least one GUI that supports git-flow for Mac and Windows SourceTree.

These days, I'm leaning more towards GitHub flow, due to its simplicity and easy to manage. Also, because of "deploy early deploy often"...

Hope this helps

Diego Antunes
  • 848
  • 1
  • 7
  • 8
  • +1. I agree with you. – VonC Sep 26 '13 at 05:57
  • 4
    GitHub flow is within Git-Flow. Think if you need continuous integration and continuous deployment you can simply run as much as possible with develop branch. Every feature is branched from develop branch. You may not need the master branch or release branches unless you have complex deployment models. (e.g. Your 1.1 version is live on some client your 1.2 is live on another client and currently you develop 1.3 for your new client) All 3 clients will ask for bug fixes and changes on their respective version. – Gayan Pathirage Jan 08 '16 at 11:24
  • Hello Diego and thank you for your answer. What about multiple version maintenance? Do you do it easily with Git Flow? I've heard it is difficult as you need support branches! Do you believe the model is well suited to do so? – Luis Gouveia Oct 31 '19 at 15:27
  • 1
    Hi Luis, I think you can make the model work, but again I feel like you can achieve the same with a standard git workflow. – Diego Antunes Nov 02 '19 at 05:39
  • 2
    @LuisGouveia actually, since your question and my reply above, I came across a project that git-flow will work perfectly, and I have ownership of the project. The idea is to use `git flow release...` in a combination with github actions to deploy the application. In my original response, I mentioned that we released multiple times in a day, this caused problems when using git-flow. The reason I think git-flow will work well in this project is because we have a pre-defined release cycle, which is one of the major selling points to use git-flow. – Diego Antunes Nov 06 '19 at 00:25
  • @DiegoAntunes, I agree, but you could use as well Microsoft's choice: Release Flow https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/ – Luis Gouveia Nov 07 '19 at 08:53