CODEWITHSUNDEEP
gitbitbucketgit-merge-conflict
Radu
Radu

Reputation: 1177

bitbucket - solve conflicts and preserve atomic feature branches

Given the following git workflow:

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?

Upvotes: 0

Views: 71

Answers (1)

LightBender
LightBender

Reputation: 4253

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

Upvotes: 2

Related Questions