Collaborating on fixing merge conflicts

Question

Scenario: Have a branch per (active) release in git, Sequence is: - Bob makes changes to R1 , commits, pulls R1 and pushes R1 to shared. Does not update R2 on shared. - Jane makes changes to R1 , commits. - Jane pulls R1 from shared, deals with any conflicts, pushes R1. - Go to Step 1 again for a few times - Jane gets told they need to bring R2 up-to-date with fixes from R1 - Jane pulls R1 and R2 from shared - Jane merges R1 into R2 locally. Merge conflicts in some area of code Bob's worked on. Jane must fetch R2 from shared and handle the merge before she can push. But, she doesn't know what to do with Bob's changes. Branches: R1, R2 ``` State of Shared Repository C1 - Bob | C2-+ - Jane | | | C3 - George | | | C4 C5 | - Bob | | C6 | - Jane [R1] | C7 - Alice [R2] ``` Bob and Jane make changes to R1 Jane then wants to merge R1 into R2 to update the latest release. She solves the merge conflicts caused by her changes, however she doesn't know how to solve the conflicts cause by the chan…

Accepted Answer

Assuming Bob is blocked and Jane is anxious to move the issue along, Jane makes her best attempt at performing the merge.

```
$ git fetch
$ git checkout R2
$ git merge --ff-only origin/R2
$ git checkout -b wip/R2-with-R1
```

Above wip stands for work in progress and is a convention that signals to the team that the tree and history are subject to radical change. Perhaps Jane really wants Bob to look over her resolutions that impact his code from R1 before integrating them into the baseline. (Note: this is an anti-pattern; a better approach would be to have automated tests that protect the desired behavior for the new code in R1 and allow developers other than Bob to merge confidently.)

Jane makes her best attempt at the merge.

```
$ git merge origin/R1
$ hack
$ git add ..
$ hack
$ git add ..
```

The wip/R2-with-R1 branch may even contain multiple checkpoint-style commits. Another good signal for each to contain would let the team know that it is speculative.

```
$ git commit -m 'FIXME: fix conflicts in Potrzebie'
```

When she is ready for Bob to look at it, she pushes it to a repository they can both see

```
$ git push --set-upstream origin wip/R2-with-R1
```

The `--set-upstream` option is there in case they need to work collaboratively on the new branch.

She then fires up her mail user agent.

```
To: Bob
From: Jane
Subject: speculative merge: wip/R2-with-R1

Bob: please look over my attempted merge in the subject branch and make
any necessary fixes that I may have overlooked.

I am particularly concerned about my Potrzebie conflict-resolutions.
Changes there always seem to bite us one way or the other.

Thanks,
Jane
```

After Bob’s fix and a fetch, the history will resemble

```
$ git lola
* 77d472c (origin/wip/R2-with-R1) fix by Bob
* ba1eb24 (HEAD, wip/R2-with-R1) FIXME: merge 2
*   80c207d FIXME: merge 1
|\
| * 2cf6ad4 (origin/R1, R1) R1 #2
* | 137b39d (origin/R2, R2) R2 #2
* | cb9a761 R2
...
```

At this point, Jane wants to preserve the merge but does not want to keep the ugly checkpoint commits. Squashing back to a merge commit requires just a bit of care.

```
$ echo Merge R1 into R2 | \
  git commit-tree origin/wip/R2-with-R1^{tree} \
  -p $(git rev-parse origin/R1) -p $(git rev-parse origin/R2)
84b177c498bc635612b66932f3d41096999e6d3f

$ git checkout R2
Switched to branch 'R2'

$ git merge --ff-only 84b177c498bc635612b66932f3d41096999e6d3f
Updating 137b39d..84b177c
Fast-forward
...
```

This leaves a history of

```
$ git lola
*   84b177c (HEAD, R2) Merge R1 into R2
|\
| | * 77d472c (origin/wip/R2-with-R1) fix by Bob
| | * ba1eb24 FIXME: merge 2
| | *   80c207d (wip/R2-with-R1) FIXME: merge 1
| | |\
| |/ /
| | /
| |/
|/|
* | 2cf6ad4 (origin/R1, R1) R1 #2
| * 137b39d (origin/R2) R2 #2
| * cb9a761 R2
...
```

and R2 now has by construction the same tree as Bob’s final tree.

Collaborating on fixing merge conflicts

Solution

Problem