Answers: <p>My favourite workflow is the <code>development</code>-less "branch per feature" workflow from Adam Dymitruk (<a href="http://dymitruk.com/blog/2012/02/05/branch-per-feature/" rel="nofollow noreferrer">http://dymitruk.com/blog/2012/02/05/branch-per-feature/</a>). It has these branches:</p>
  
  <ul>
  <li>Exactly one <code>master</code> in an unbroken line from day 0 up to the version of your app that is currently in production.</li>
  <li>Many <code>feature-...</code> branches.</li>
  <li>One (or if you are so inclined more) <code>qa</code> branch.</li>
  </ul>
  
  <p>The gory details can be found on Adam's site, but in short:</p>
  
  <ul>
  <li><em>Every</em> branch goes off of <code>master</code>.</li>
  <li>All branches that are in active testing are merged into <code>qa</code>.</li>
  <li><code>qa</code> <em>only</em> ever contains merge commits (i.e. feature branches merged on top of each other, starting from <code>master</code>), <em>never</em> direct manipulations.</li>
  <li>Whenever a feature branch gets new commits, and you want those in <code>qa</code>, you rebuild <code>qa</code> from scratch.</li>
  <li>Whenever you want to deploy a bunch of features, you create a <code>qa</code> from all of them, test to your heart's content, and then simply rename that branch to the new <code>master</code> (which, as it started out from the old <code>master</code>, will be a direct, unbroken line of merge commits from day 0). Then, all feature branches are rebased on that.</li>
  <li>One fundamentally important part for this workflow is to enable the <code>git rerere</code> cache feature, and distribute that cache between all developers. Hence, every merge conflict needs to be resolved only once, globally.</li>
  </ul>
  
  <p>It's trivial to have more than one <code>qa</code> branch at a time to test different subsets of features; in your case, you could have <code>qa</code> (with everything nearly close to finished, i.e., compiles without error), <code>qa-acceptance</code>, <code>qa-staging</code> or whatever you like.</p>
  
  <p>In my experience, there is always a relatively large main, ongoing <code>qa</code> branch (recreated from the master and features regularly), and when some features are picked for release, the will be a temporary smaller <code>qa-...</code>. </p>
  
  <p>It is trivial to add and remove individual features from the set of <code>qa</code> or release-candidate branches on the fly, as those are recreated constantly and only ephemeral.</p>
  
  <p>You will find a lot of people very much objecting to <code>git rebase</code>, but if one wraps their mind around the fact that this is just a tool like any other, it will be fine. You need good tooling for this of course, but this is not complicated to program yourself; the actual <code>git</code> commands are all pretty simple and self-explanatory.</p>
  
  <p>We have extended the workflow (or rather our tooling) to even allow arbitrary sub-features (i.e., feature branches going off of another feature branch, not <code>master</code>), so multiple branches can go off of a common ancestor which is not yet in production; works like a charm. But you can get pretty far without this.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-11-19T20:04:06.080Z
Answers: Does your team grow ot stable? Does it have any git newbies, who tend to do everything wrong?
Answers: jonny
Answers: CC BY-SA 4.0
Answers: 2018-06-18T19:08:07.707Z
Answers: 2018-06-18T19:08:07.707Z
Answers: AnoE
Answers: <p>well, gitflow is your friend here. 
  <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-19T14:39:51.300Z
Answers: 2018-04-19T14:39:51.300Z
Answers: prashant tyagi
Body: <p>I'm trying to streamline/standardize a git workflow in my workplace. The current delopment process is as follows:</p>
  
  <ol>
  <li>Pull 'development' branch </li>
  <li>Write code and commit and push to 'development' branch</li>
  <li>Cherry pick from 'development' into 'testing' branch for User Acceptance Testing</li>
  <li>Cherry pick from 'testing' into 'staging'</li>
  <li>'staging' is merged into 'master' once a week</li>
  </ol>
  
  <p>I want to adopt a 'feature branch' work flow with testing, staging and master. Thus I don't think there is any need for 'development'. From waht I gather, feature branches should be taken from 'master'. </p>
  
  <p>What I'm having trouble understanding is how to fit in the 'testing' and 'staging' environments into a 'feature branch' git workflow.</p>
  
  <p>Can someone explain how that might work?</p>
  
Tags: <deployment><git><continuous-deployment><gitlab><workflow>
Title: Git Workflow with User Acceptance and Staging Environments
UserDisplayName: David
ThreadText: # Git Workflow with User Acceptance and Staging Environments
  
  (Asked by: username_0 on 2018-04-19)
  
  I'm trying to streamline/standardize a git workflow in my workplace. The current delopment process is as follows:
  
  1. Pull 'development' branch
  2. Write code and commit and push to 'development' branch
  3. Cherry pick from 'development' into 'testing' branch for User Acceptance Testing
  4. Cherry pick from 'testing' into 'staging'
  5. 'staging' is merged into 'master' once a week
  
  I want to adopt a 'feature branch' work flow with testing, staging and master. Thus I don't think there is any need for 'development'. From waht I gather, feature branches should be taken from 'master'.
  
  What I'm having trouble understanding is how to fit in the 'testing' and 'staging' environments into a 'feature branch' git workflow.
  
  Can someone explain how that might work?
  
  **Tags:** deployment, git, continuous-deployment, gitlab, workflow
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-06-18. Score: 2
  
  My favourite workflow is the `development`-less "branch per feature" workflow from Adam Dymitruk (<http://dymitruk.com/blog/2012/02/05/branch-per-feature/>). It has these branches:
  
  * Exactly one `master` in an unbroken line from day 0 up to the version of your app that is currently in production.
  * Many `feature-...` branches.
  * One (or if you are so inclined more) `qa` branch.
  
  The gory details can be found on Adam's site, but in short:
  
  * *Every* branch goes off of `master`.
  * All branches that are in active testing are merged into `qa`.
  * `qa` *only* ever contains merge commits (i.e. feature branches merged on top of each other, starting from `master`), *never* direct manipulations.
  * Whenever a feature branch gets new commits, and you want those in `qa`, you rebuild `qa` from scratch.
  * Whenever you want to deploy a bunch of features, you create a `qa` from all of them, test to your heart's content, and then simply rename that branch to the new `master` (which, as it started out from the old `master`, will be a direct, unbroken line of merge commits from day 0). Then, all feature branches are rebased on that.
  * One fundamentally important part for this workflow is to enable the `git rerere` cache feature, and distribute that cache between all developers. Hence, every merge conflict needs to be resolved only once, globally.
  
  It's trivial to have more than one `qa` branch at a time to test different subsets of features; in your case, you could have `qa` (with everything nearly close to finished, i.e., compiles without error), `qa-acceptance`, `qa-staging` or whatever you like.
  
  In my experience, there is always a relatively large main, ongoing `qa` branch (recreated from the master and features regularly), and when some features are picked for release, the will be a temporary smaller `qa-...`.
  
  It is trivial to add and remove individual features from the set of `qa` or release-candidate branches on the fly, as those are recreated constantly and only ephemeral.
  
  You will find a lot of people very much objecting to `git rebase`, but if one wraps their mind around the fact that this is just a tool like any other, it will be fine. You need good tooling for this of course, but this is not complicated to program yourself; the actual `git` commands are all pretty simple and self-explanatory.
  
  We have extended the workflow (or rather our tooling) to even allow arbitrary sub-features (i.e., feature branches going off of another feature branch, not `master`), so multiple branches can go off of a common ancestor which is not yet in production; works like a charm. But you can get pretty far without this.
  
  > **Comments:**
  > **username_2**: Does your team grow ot stable? Does it have any git newbies, who tend to do everything wrong?  
  
  ---
  
  ### Answer by username_3 on 2018-04-19. Score: 0
  
  well, gitflow is your friend here.
  <http://nvie.com/posts/a-successful-git-branching-model/>
  
  
  ---
  
  