What branching strategies/workflows are available for Git repositories?

Question

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.

Answer 1

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.

Answer 2

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