2

I am currently in the middle of planning a new Git flow in my company and the new idea for it is to migrate over to forking and pull requests as well as add a staging branch for testing.

The proposed branch spec

  • master (development) - contains bleeding-edge code from developers feature/bug branches
  • staging - pre-production codebase that would be autodeployed to a staging server. Tested by end-customer.
  • production - fully tested production-ready code that is autodeployed to the production server.

So eventually it would be something like: master -> staging -> production

Proposed setup flow

  • there is the official upstream repo from which every developer forks their own origin repo
  • they clone that to their local development

Proposed dev flow

  • create a feature/bug branch from master
  • coffee2code magic
  • When finished, they create a pull request to upstream/master from their branch

At this state other co-worker(s) would have a look at that PR and offer either suggestions or finally merge it in to upstream/master from where the feature should eventually end up in staging for QA and then ff merged into production if tests pass.

Now the challenging part comes to moving the tested stuff to staging for testing by the end-customer to accept the changes.

The possible approaches I've thought about:

  • Merging changes from master to staging - Whereas this seems the most simple way, it for some reason feels the most dangerous as well as unfinished code can end up in staging which in term might fail tests by end-customer.

  • Cherry-picking from master to staging - A bit more safer than the above approach but might become tedious at some point (?)

  • Merging the feature branch to upstream/staging - This most probably won't work as the feature branch is not available on upstream

  • Make pull requests to upstream/staging directly - While this is quite convenient but lacks the use of the master branch (if PR is made to staging, master would have to be rebased from staging. Might not be a good idea?).

What would be the best or ideal practice in this case to move features from upstreams master to staging for QA in a clean way? Or am I just over-complicating things at this point already?

Karl Viiburg
  • 832
  • 10
  • 34
  • How big is your team/company? This sounds a bit over-engineered to me. The one thing which really grinded my gears was the suggestion to cherry-pick from master to staging. The problem with this is that if you ever want to merge master into staging down the road you might be bringing in the same commits a second time. – Tim Biegeleisen Jun 30 '16 at 13:10
  • @TimBiegeleisen Currently for the project I am proposing this idea to is at the moment 8 but due to the company and project vastly growing it might hit over 10 and more in no time. Yes I feel that cherry-picking might become tedious and a cluster of mess in a short period. I was putting all the possible resolutions on the table that I could come up which would lead to the end goal. – Karl Viiburg Jun 30 '16 at 13:15
  • Whats wrong w/ just following standard [gitflow](http://nvie.com/posts/a-successful-git-branching-model/) and feature branching? your production branch becomes master... No need to over-complicate things... – g19fanatic Jun 30 '16 at 13:52
  • @g19fanatic Hmm okay. So if I move `master` to be the production branch, would I still be able to utilize `staging` as a test environment in between for end-customer QA? Since at the end when something is pushed to staging branch, it would go through CI and CD and same for production branch (to become master). Or would it be applicable that pull requests are made to `staging` (PRs will be under CI as well) and then have an automatic rebasing to development branch so the developers forks would be up to date as well? – Karl Viiburg Jun 30 '16 at 14:37
  • see my answer on this question which covers an extension of the gitflow model. This approach allows for testing/testing delays in the various in-test environments.http://stackoverflow.com/questions/38048843/git-branching-model-strategy/38058329#38058329 – ManxJason Jul 01 '16 at 12:10

0 Answers0