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. – Jiri Klouda Mar 2 '17 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 Mar 2 '17 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 – Dan Cornilescu Mar 2 '17 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 Mar 2 '17 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? – Dan Cornilescu Mar 2 '17 at 16:03

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. – Dan Cornilescu Aug 22 '17 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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