2

A developer starts work on a feature lets call it "Fix a hardcoded link", once it's done, it's passed to another developer for peer review. Peer reviewer is ok with code changes and merge feature branch into test branch. "Fix a hardcoded link" is now on test server waiting for Technical test.

test is where feature branches are merged once it's been peer reviewed by another developer, staging is the branch where feature branches are merged once it's gone through Peer review, TT and UAT.

Next developer starts working on the next card and creates a branch like this: 

git checkout test
git checkout -b story/bar

Developer finishes work and passes it to peer review. Peer reviewer is happy with the code an passes into TT and UAT, all are happy and onto P.O it goes. P.O is happy then he merge feature branch into staging

git checkout staging
git merge origin/story/bar

By doing that I have discovered that we are applying not only the patch attached to the fix for the particular card but also the whole history that comes with the branch. The result is the commit "Fix a hardcoded link" is staging but it hasn't gone through the process.

  • Is there anything wrong with our approach and any suggestions to imrpove it?
  • Should we create our feature branches out of staging?
filype
  • 8,034
  • 10
  • 40
  • 66
  • 1
    Yes, if you want to review fixes separately from others, you should create (and merge back) branches that include only them (and not unrelated stuff). – Thilo Mar 27 '13 at 04:24

1 Answers1

1

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).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the feedback, After reading the links you've posted I am starting to see a need for a "release candidate branch" rather than staging, then we can create feature branches from "release candidate branch" instead of test – filype Mar 27 '13 at 08:22
  • @Filype true, some kind of "official" branch, which all developers can use as a reference. But the rebase parts are important too. – VonC Mar 27 '13 at 08:24