Basically, you need to take into account the publication workflow (push/pull), and not just the merge workflow (feature
to test
to staging
to...): this publication workflow is orthogonal to a merge workflow.
Any new feature
branch must be developed on top of the LATEST official version you want to use that feature
with.
If it is staging
, that means:
git fetch
git checkout -b newFeature origin/staging
# hack...
# make sure newFeature still works on top of staging as right now
# since staging might have received other feature
# during the development of newFeature
git fetch
git rebase origin/staging
# local and/or unit tests...
# push for review
git push -u origin newFeature
When you are merging a feature
to test
or staging
, you should rebase newFeature
on top of test
, then on top of staging
, and merge newFeature
only then (fast forward merge).
Any conflict during the rebase means the feature is rejected (the developer must fetch, then rebase that newFeature
branch locally on top of what is causing trouble, in order to see why there is a conflict).