I'm looking for a high-level, summary description of the recommended branching strategies/workflows primarily applicable with Git, which would serve as a guide for navigating this environment.

Ideally a summary of pros/cons and maybe intended usage of such strategies/workflows should be mentioned as well.

  • 3
    This really is too broad. The strategies depend on size of team, maturity of code and type of software (App, SaaS, etc). Restticting the question on those categories would make it answerable. Commented Mar 2, 2017 at 14:53
  • Please describe the nature of the product you are using git for and the size of your team or current technologies used so a useful answer can be given. Otherwise, read this: atlassian.com/git/tutorials/comparing-workflows
    – avi
    Commented Mar 2, 2017 at 15:01
  • Personally I'm already a fan single-branch development, the question is just to serve as a home for this answer, IMHO valuable: devops.stackexchange.com/a/126/47 Commented Mar 2, 2017 at 15:06
  • 1
    Please refer to devops.stackexchange.com/help/dont-ask and rescope your question! A more specific question will get you better answers.
    – Alexandre
    Commented Mar 2, 2017 at 15:11
  • 2
    @avi OK, now you can reference Evgeny's answer to this post instead of an external link. Isn't DevOps a tiny bit more valuable than before? Commented Mar 2, 2017 at 16:03

2 Answers 2


The Atlassian website includes a comparison of different workflow strategies available when concerned with Git. More strategies exist, like the one used by Linux Kernel team, but are not relevant to most organisations.

The workflow types most commonly used are -

  1. Centralized - every change is added using a single branch.
  2. Feature Branch - every change is added on its own branch and considered for merging into a central branch for integration.
  3. Gitflow - based on feature branch workflow, but also adds another branch for stable releases, and another bunch of branches for hotfixes on that stable release branch.
  4. Forking - in OSS projects often the whole project is copied over to an additional repository and changes are merged between multiple public repositories, or not merged, but still available to the public.

Depending on the organization, one of these might be more suitable.

  1. Centralized - non-restrictive, allows everyone to shoot anyone to "break the build" by pushing changes, least overhead and process involved. The advantage is a continuous integration of changes, even when those don't work.
  2. Feature branch - allows anyone to add changes by adding some overhead process, but integration into main collaborative work is a controlled process. Has the disadvantage of integrating changes late, when requests to merge are forgotten or not attended.
  3. Gitflow - huge overhead in managing the various branches, causes a lot of confusion for regular people who just want to get their changes into the branch. Can work well when most developers only see the "feature branch" part of this. Merging between the development and stable branches often happens late, and integration is not trivial. Adds a lot of extra overhead and terminology that everyone must understand well.
  4. Forking - the wild west, requires a server that supports managing multiple repositories and repositories per-user (GitHub, GitLab, BitBucket Server, etc...). Allows most freedom for each contributor to do whatever he wants, but does not force integration. Demands that integration is done piecemeal in small bits and very controlled, usually by using pull requests across repositories. Works well in unorganized teams such as OSS project contributors.

You can read book about best practices for git: https://git-scm.com/book/en/v2

Example for some git strategy in project:

  1. Creates branch named like a task, feature/XXX-1
  2. Sending task for review
  3. If not review, fixes and again review
  4. If reviewed go to test
  5. If test not passed, fixed and again review/tests

First time review:

git pull dev
git checkout -b feature/XXX-1
git add .
git commit -m 'XXX-1 My task'
git push origin feature/XXX-1

If need fixed after review:

git push origin :feature/XXX-1
git reset --soft HEAD~1
git add .
git commit -m 'XXX-1 My task fix'
git push origin feature/XXX-1
  • Good reference, but the example contains a very bad practice which unfortunately git provides support for: re-writing history. My advice would be to never, ever, do that in a larger development team. Commented Aug 22, 2017 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.