3

We use long-lived branches PROD, TEST et DEV.

Next app version is developped in DEV, it is merged in TEST when ready to be tested, and merged in PROD once released.

Some commits are made directly in TEST branch (for bug correction of the version being tested) and in PROD (for maintenance bug).

These commits in PROD and TEST are always "merged down" into child branches (ie: PROD merged in TEST and DEV; TEST merged in DEV).

Once in a while, a bug correction is committed in PROD, then merged down in TEST and DEV, then pushed to origin. But then, there is some changes in the planning and the bug correction should be part of the version in TEST instead of the one in PROD.

Now here is the problem : if I revert the commit in PROD, the revert will be done also in TEST and DEV when PROD is merged down. How to proceed to remove the changes in PROD and keep it in TEST and DEV even after PROD is merged down ?

What I currently do is, from TEST: 

git merge PROD --no-commit

This allow me to discard reverted changes from PROD before the merge is committed in TEST. Then do a merge from TEST to DEV with no special interventions. If the only commit to be merged from PROD is the reverted one, this result in a merge with no file ... but this seems to work nonetheless.

So I was wondering if my approach is correct or if there is better way to do this ?

Guillaume Morin
  • 3,910
  • 6
  • 25
  • 40

1 Answers1

3

In general it's a bad idea to merge your production branch back into a testing branch. It should normally be git checkout PROD followed by git merge TEST. (If you want to know more about this rule of thumb, this blog post on merging and branches gives a full justification.)

If someone accidentally commits a fix in PROD which was meant to be on TEST, you should probably cherry-pick that fix onto TEST and revert it on PROD. To describe that step-by-step, let's assume that the commit with the fix on PROD has object name A. Then: 

 # cherry-pick the commit onto `TEST`.
 git checkout TEST
 git cherry-pick A

 # Now revert the commit on `PROD`:
 git checkout PROD
 git revert A

Now when you merge TEST into PROD, the fix should be merged in. (Depending on the history, it might produce a conflict, but if so this should be easy to resolve in favour of the version on TEST.)

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • Sorry, but I don't understand your suggestion of merging TEST into PROD ... it is the other way around, I want to keep TEST up-to-date with PROD, until TEST is ready to release(only at that time TEST is merged in PROD). – Guillaume Morin Oct 27 '11 at 15:13
  • Looking at the blog post you mention, I'm not sure i get the full justification about not merging an integration branch(parent) into a feature branch(child). In our situation, at the philosophical point of view, we could say that the purpose of every child branch is "Add features xxx (to the latest version of parent branch)", and not "Add features xxx (to the version the branch forked from)". We don't mind not being able to merge TEST to older codebase of PROD (ex: last merge of TEST in PROD) as we have only one production version of the app and not any customer specific versions. – Guillaume Morin Oct 27 '11 at 15:13
  • At the thechnical point of view, I thought merging parent into child was better than cherry-picking... as my quick try with cherry-pick resulted in many conflict once a child branch is merged back into its parent. – Guillaume Morin Oct 27 '11 at 15:14
  • @Guillaume Morin: Using `git cherry-pick` is the standard way, I believe, to pick a single bug-fix commit from one branch to another where you don't necessarily want all the other commits in that branch. (See [this question](http://stackoverflow.com/q/1440181/223092), for example.) If you're happy merging `PROD` into `TEST`, and the way that you interpret the purposes of those branches makes sense in the context of that post's guidance, that's fine - I'm just describing what I would normally consider to be good practice. :) – Mark Longair Oct 27 '11 at 16:00
  • I'm surprised that merging a branch that contains a cherry-picked commit creates so many conflicts, particularly if it had been reverted in your `HEAD`. – Mark Longair Oct 27 '11 at 16:02