Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-22T21:56:46.707Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-08-22T18:59:26.337Z
Answers: 2017-08-22T19:06:52.237Z
Answers: 2017-08-22T19:06:52.237Z
Answers: Quarind
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-02T15:47:16.983Z
Answers: 2017-03-02T15:47:16.983Z
Answers: Evgeny Zislis
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-21T19:21:41.943Z
Comments: 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)?
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-02T14:53:56.913Z
Comments: 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.
Comments: Jiri Klouda
Comments: CC BY-SA 3.0
Comments: 2017-03-02T15:01:45.203Z
Comments: 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
Comments: avi
Comments: CC BY-SA 3.0
Comments: 2017-03-02T15:06:56.763Z
Comments: 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
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2017-03-02T15:09:31.937Z
Comments: @DanCornilescu Interesting yes, better with the summary oriented wording now.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-02T15:11:08.357Z
Comments: Please refer to http://devops.stackexchange.com/help/dont-ask and rescope your question! A more specific question will get you better answers.
Comments: Alexandre
Comments: CC BY-SA 3.0
Comments: 2017-03-02T16:03:48.810Z
Comments: @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?
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2017-03-02T19:16:49.160Z
Comments: 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.
Comments: Tensibai
Tags: <git><branch><workflow>
Title: What branching strategies/workflows are available for Git repositories?
UserDisplayName: Dan Cornilescu
ThreadText: # 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 navigating 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**: @username_0 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 username_7'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:
  
  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
  
  ```
  
  > **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.  
  
  ---
  
  