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?

2 Answers 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.

  • Does your team grow ot stable? Does it have any git newbies, who tend to do everything wrong?
    – jonny
    Nov 19, 2020 at 20:04

well, gitflow is your friend here. http://nvie.com/posts/a-successful-git-branching-model/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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