Git: using nvie's gitflow concept with staging environment

Question

we are using nvie's gitflow as a pattern for our git branching strategy and follow it more or less fairly close.

The main difference is a staging environment, which I have to integrate in the existing strategy.

It is fairly straight forward at first. Staging is not much more than just a simple branch we can merge with a new release branch. Push it to origin/stageserver and do what we want to do during staging. So far so good.

But let's say we find stuff in staging we would like to correct (minor bugfixes, maybe even an error in a newly integrated feature?) . To me it is not clear yet, what is a good strategy to handle this case.

My current ideas surround the following strategy:

• create a branch staging_fix from origin/staging
• correct errors
• rerun staging process + tests
• merge staging_fix branch with release branch
• pull release branch from origin
• continue with gitflow according to nvie, hence prepare release branch for production etc...

Do you think this is a good idea? This would result in direct changes to the staging branch, which seems like a shortcut to me, because I'd have to tinker with the staging environment directly - something you wouldn't do to your production environment and I want staging to be as similar to production as possible.

Alternatively one could correct the release branch directly and push it to staging again and again until all errors are solved. At least now we had a one way street of doing changes.

Which way would you prefer? Would you suggest a different strategy here all the way?

Answer 1

It seems to be a good strategy, because:

• it isolates staging (and its associated merge workflow) in a repo (on the staging server)
• it allows to pull from that staging server what you need to re-integrate and merge back into your own dev repo.

This only becomes cumbersome if the fixes done in the staging repo (as opposed as fixes done in your repo and push to staging) take too much time, and the merge back becomes too complex (because of a large gap in code modification).

Answer 2

If you follow the git flow pattern and within my understanding, this is how we should proceed: - work on your feature, when it's finished, you merge it back into your develop branch git flow finish feature MyFeature

• If you want to test your feature, create a release branch git flow release start YourRelease , it will contains all features finished and merged back into your branch develop.

• deploy your release branch in your staging environment, fix bugs in release branch, redeploy branch, fix bugs, etc... until you are happy with you release branch.

• When release branch is ready to deploy git flow finish release YourRelease which will merge relase into master and staging.

• deploy the master branch into your production environment.

The problem I can see with this is if a features merged into staging needs to be removed (too buggy, changes in features plans, etc..), you are stuck with a feature you don't want anymore in develop and release branches and you cannot continue with other features/release until this feature is undone...