<p>You can read book about best practices for git: <a href="https://git-scm.com/book/en/v2" rel="nofollow noreferrer">https://git-scm.com/book/en/v2</a></p>

<p>Example for some git strategy in project:</p>

<ol>
<li>Creates branch named like a task, feature/XXX-1</li>
<li>Sending task for review</li>
<li>If not review, fixes and again review</li>
<li>If reviewed go to test</li>
<li>If test not passed, fixed and again review/tests</li>
</ol>

<p>First time review:</p>

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

<p>If need fixed after review:</p>

<pre><code>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
</code></pre>

CC BY-SA 3.0
2017-08-22T21:56:46.707Z
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
CC BY-SA 3.0
2017-08-22T18:59:26.337Z
2017-08-22T19:06:52.237Z
2017-08-22T19:06:52.237Z
Quarind
<p>The Atlassian website includes a <a href="https://www.atlassian.com/git/tutorials/comparing-workflows" rel="noreferrer">comparison of different workflow strategies</a> available when concerned with Git. More strategies exist, like the one used by Linux Kernel team, but are not relevant to most organisations.</p>

<p>The workflow types most commonly used are -</p>

<ol>
<li><a href="https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow" rel="noreferrer">Centralized</a> - every change is added using a single branch.</li>
<li><a href="https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow" rel="noreferrer">Feature Branch</a> - every change is added on its own branch and considered for merging into a central branch for integration.</li>
<li><a href="https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow" rel="noreferrer">Gitflow</a> - 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.</li>
<li><a href="https://www.atlassian.com/git/tutorials/comparing-workflows#forking-workflow" rel="noreferrer">Forking</a> - 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.</li>
</ol>

<p>Depending on the organization, one of these might be more suitable.</p>

<ol>
<li>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.</li>
<li>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.</li>
<li>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 <em>lot</em> of extra overhead and terminology that everyone must understand well.</li>
<li>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.</li>
</ol>

CC BY-SA 3.0
2017-03-02T15:47:16.983Z
2017-03-02T15:47:16.983Z
Evgeny Zislis
<p>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.</p>

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

CC BY-SA 3.0
2017-03-21T19:21:41.943Z
Am I the only one who thinks that most, if not all, of the previous comments are obsolete now (now that the question is reopened, as per what I can see in the timeline of it)?
Pierre.Vriens
CC BY-SA 3.0
2017-03-02T14:53:56.913Z
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
CC BY-SA 3.0
2017-03-02T15:01:45.203Z
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:  https://www.atlassian.com/git/tutorials/comparing-workflows
avi
CC BY-SA 3.0
2017-03-02T15:06:56.763Z
Personally I'm already a fan single-branch development, the question is just to serve as a home for this answer, IMHO valuable: http://devops.stackexchange.com/a/126/47
Dan Cornilescu
CC BY-SA 3.0
2017-03-02T15:09:31.937Z
@DanCornilescu Interesting yes, better with the summary oriented wording now.
Tensibai
CC BY-SA 3.0
2017-03-02T15:11:08.357Z
Please refer to http://devops.stackexchange.com/help/dont-ask and rescope your question! A more specific question will get you better answers.
Alexandre
CC BY-SA 3.0
2017-03-02T16:03:48.810Z
@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
CC BY-SA 3.0
2017-03-02T19:16:49.160Z
To be honest, this is still a little bit biased :) It's ok with the answer and being closed, it makes a canonical reference to close duplicates while showcasing too broad anyway.
Tensibai
<git><branch><workflow>
What branching strategies/workflows are available for Git repositories?
Dan Cornilescu
# What branching strategies/workflows are available for Git repositories?

(Asked by: username_0 on 2017-03-02)

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 nusername_3gating this environment.

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

**Tags:** git, branch, workflow

> **Comments:**
> **username_2**: 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.  
> **username_3**: 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:  https://www.atlassian.com/git/tutorials/comparing-workflows  
> **username_0**: Personally I'm already a fan single-branch development, the question is just to serve as a home for this answer, IMHO valuable: http://devops.stackexchange.com/a/126/47  
> **username_4**: @DanCornilescu Interesting yes, better with the summary oriented wording now.  
> **username_5**: Please refer to http://devops.stackexchange.com/help/dont-ask and rescope your question! A more specific question will get you better answers.  
> **username_0**: @username_3 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?  
> **username_4**: To be honest, this is still a little bit biased :) It's ok with the answer and being closed, it makes a canonical reference to close duplicates while showcasing too broad anyway.  
> **username_1**: Am I the only one who thinks that most, if not all, of the previous comments are obsolete now (now that the question is reopened, as per what I can see in the timeline of it)?  

---

## 2 answers

### Answer by username_7 on 2017-03-02. Score: 11 | Accepted answer

The Atlassian website includes a [comparison of different workflow strategies](https://www.atlassian.com/git/tutorials/comparing-workflows) 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](https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow) - every change is added using a single branch.
2. [Feature Branch](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) - every change is added on its own branch and considered for merging into a central branch for integration.
3. [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) - 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](https://www.atlassian.com/git/tutorials/comparing-workflows#forking-workflow) - 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 by username_6 on 2017-08-22. Score: 2

You can read book about best practices for git: https://git-scm.com/book/en/v2
Example for some git strategy in project:

Creates branch named like a task, feature/XXX-1
Sending task for review
If not review, fixes and again review
If reviewed go to test
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

> **Comments:**
> **username_0**: 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.  

---

