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

Answer 1

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

Answer 2

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

---

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

Answer 3

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.