0

Given the following git workflow:

  • a feature branch fb1 is created from master branch (production stable codebase)
  • when dev done a pull-request is created, then fb1 is merged to release-branch-1.x.x
  • another feature branch fb2 is created from master
  • when dev is done on fb2 another pull-request is created and attempted to be merged to release-branch-1.x.x but fails due to a conflict (most likely introduced by some code in fb1)

According to the documentation solving this conflict implies that release-branch-1.x.x (which contains fb1 code) be merged in fb2 locally, decide what to keep (solve conflict), then fb2 be pushed to remote to update the pull-request.

This solves the conflict all right, but adds all the work on release-branch-1.x.x to fb2 which is something I would like to avoid. Say I want to revert the fb1 merge commit, the fb1 code will still be on the release branch because it was introduced by fb2.

Any thoughts on how can this be avoided?

Radu
  • 1,159
  • 3
  • 22
  • 40

1 Answers1

2

In most workflows, the owner of each feature branch is responsible for keeping their branch up to date with whatever the "official" line of code is (To be as generic as possible, I'll call the integration branch master, though it can be develop, release, or other name in various workflows). So the full sequence for your scenario would look like this:

  1. Developer 1 starts fb1 from master
  2. Developer 2 starts fb2 from master
  3. Developer 1 completes his feature and submits pr1 to merge fb1 into master
  4. fb1 is tested and approved and pr1 is accepted, master is updated to contain initial + fb1
  5. Developer 2 completes her feature but finds her branch is now out of date
  6. Developer 2 merges master into fb2 and resolves the conflicts her branch now contains initial + fb1 + fb2
  7. Developer 2 submits a pr2 to merge fb2 into master
  8. A serious bug is found resulting from feature1, so the merge of fb1 to master is reverted and master now contains initial only
  9. fb2 is now out of date because master has been altered and if there were conflicts resolved before, they will occur again with the original code restored so that pr2 will not be able to automatically merge and bitbucket will warn you.
  10. Developer 2 merges master into fb2 and resolve the conflicts, making her branch contain initial + fb2
  11. Developer 2 pushes to update pr2 which is then approved and merged, resulting in a master branch that contains initial + fb2

Git uses the most recent common ancestor of two commits when merging, not the original point where the code diverged. Even if there were no conflicts, when the changes from master including fb1, are integrated into fb2, the common ancestor between those two branches would be a point on master containing initial + fb1, if fb1 was subsequently removed from master, git would see those changes had occurred on the master branch and the resulting merge would not contain those changes.

You can think of a merge algebraically, where m = merge, b = base, l = left, r = right, f = feature and i = initial

m = b        + diff(b,l)           + diff(b,r)
m = (i + f1) + diff((i + f1), (i)) + diff((i + f1), (i + f1 + f2))
m = (i + f1) + (-f1)               + (f2)
m = i  + (f1 + -f1)                + (f2)
m = i + f2
LightBender
  • 4,046
  • 1
  • 15
  • 31
  • what would have happened if the pr2 would have been merged before the bug was found (step 7). btw, that's a really nice explanation @LightBender – Radu Apr 03 '18 at 05:30
  • adding to the comment above: pr1 would be reverted but pr1 code would still remain on master because it was also introduced when pr2 was merged (which at the time of merge contained pr1 code from the sync with master) – Radu Apr 03 '18 at 05:39
  • @Radu Reverting a commit does not remove the commit from the history, instead a new commit that reverses the changes is added. So reverting the changes on pr1 would remove those changes from master entirely regardless of how many intermediate commits contained that code. – LightBender Apr 03 '18 at 13:46