Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Assuming Bob is blocked and Jane is anxious to move the issue along, Jane makes her best attempt at performing the merge.</p> <pre>$ git fetch $ git checkout R2 $ git merge --ff-only origin/R2 $ git checkout -b wip/R2-with-R1</pre> <p>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.)</p> <p>Jane makes her best attempt at the merge.</p> <pre>$ git merge origin/R1 $ <i>hack</i> $ git add .. $ <i>hack</i> $ git add ..</pre> <p>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.</p> <pre>$ git commit -m 'FIXME: fix conflicts in Potrzebie'</pre> <p>When she is ready for Bob to look at it, she pushes it to a repository they can both see</p> <pre>$ git push --set-upstream origin wip/R2-with-R1</pre> <p>The <code>--set-upstream</code> option is there in case they need to work collaboratively on the new branch.</p> <p>She then fires up her mail user agent.</p> <pre>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</pre> <p>After Bob’s fix and a fetch, the history will resemble</p> <pre>$ 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 ...</pre> <p>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.</p> <pre>$ 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 ...</pre> <p>This leaves a history of</p> <pre>$ 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 ...</pre> <p>and R2 now has by construction the same tree as Bob’s final tree.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload