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

Solution 1:

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

Solution 2:

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.