Skip to main content

Git for Authors

Section 3.2 Conflicting Edits

Let us do one more exercise with Alice and Bob.

Checkpoint 3.2.1. Alice and Bob Edit Simultaneously.

With agreement about the recommendations, and in a rush, both Alice and Bob are going to simultaneously perform conflicting edits in the recommendations section. We will purposely engineer a merge conflict as an exercise, so follow the instructions carefully.
Alice should make a new branch, named rec, for her work on the recommendations. She should write three short paragraphs in recommendations.txt, separated by blank lines, and she should commit those changes on her branch. Bob should make a new branch, named recommend, and should also author three short paragraphs in recommendations.txt, separated by blank lines, and he should commit those changes on his branch. However, Alice and Bob should collude (outside of GitHub) to have identical first and third paragraphs, but radically different second paragraphs. Of course, this is unrealistic, but this makes the exercise work. If you put Alice’s name into her second paragraph someplace, and put Bob’s name into his second paragraph, the exercise will be even more informative.
We will let Alice go first, since she got a head-start on Bob originally and she does not yet have the section with the technical details of the vulnerability. Alice updates her master branch from the definitive repository (origin/master), and in doing so, she will pickup Bob’s technical section. Then she should rebase her rec branch onto master, which will go smoothly. Then she merges rec into her local master (which will be a fast-forward merge) and push the improved master to origin/master.
So the definitive repository has Alice’s recommendation section, while Bob’s recommendations are still local to his repository, and origin/master has advanced beyond Bob’s local master. Here is the transcript for Bob (again).
bob@laptop:~/publications/banking-paper$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
bob@laptop:~/publications/banking-paper$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/alice-jones/banking-paper
   bceacaa..b7abe18  master     -> origin/master
Updating bceacaa..b7abe18
Fast-forward
 recommendations.txt | 5 +++++
 1 file changed, 5 insertions(+)
bob@laptop:~/publications/banking-paper$ git checkout recommend
Switched to branch 'recommend'
bob@laptop:~/publications/banking-paper$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Bob recommends
Using index info to reconstruct a base tree...
M       recommendations.txt
Falling back to patching base and 3-way merge...
Auto-merging recommendations.txt
CONFLICT (content): Merge conflict in recommendations.txt
Failed to merge in the changes.
Patch failed at 0001 Bob recommends
The copy of the patch that failed is found in:
   ~/publications/banking-paper/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Boom! The scariest thing that can happen in git. But you know we engineered this conflict to happen and we are not going to panic. (If you do want to panic, try git rebase --abort as suggested and when you collect yourself and settle down, come back to try the rebase again.)
Your hint about where the conflict lies is in the line
CONFLICT (content): Merge conflict in recommendations.txt
Details on resolving conflicts are in Chapter 5 so head there for details on what to do now, specifically see the instructions for a “rebase conflict” in List 5.0.1. Briefly, Bob will open recommendations.txt in his editor and see the two different second paragraphs adjacent to each other, with Alice’s official second paragraph first, and his proposed second paragraph afterwards. Now there is no notion of official or not, Bob and Alice are equals. But Alice got there first, so Bob has the responsibility to decide which paragraph to keep, or to keep both, and in what order. If Alice does not like Bob’s decisions, they can do another round of changes (perhaps after some discussion on a GitHub issue, including commit hashes in the discussion to reference the details of any disagreement).
Done resolving the conflict, Bob’s recommend branch now comes off the tip of master and is positioned for a fast-forward merge that he can then push to origin/master.
bob@laptop:~/publications/banking-paper$ git show-branch
! [master] Recs by Alice
 * [recommend] Bob recommends
--
 * [recommend] Bob recommends
+* [master] Recs by Alice
bob@laptop:~/publications/banking-paper$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
bob@laptop:~/publications/banking-paper$ git merge recommend
Updating b7abe18..3bd7a4a
Fast-forward
 recommendations.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
bob@laptop:~/publications/banking-paper$ git push
Username for 'https://github.com': bob-smith
Password for 'https://bob-smith@github.com': xxxxxxxx
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 346 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/alice-jones/banking-paper.git
   b7abe18..3bd7a4a  master -> master
bob@laptop:~/publications/banking-paper$ git branch -d recommend
Deleted branch recommend (was 3bd7a4a).
bob@laptop:~/publications/banking-paper$ git show-branch
[master] Bob recommends
Of course, now Alice does not have the edits Bob made when adding his recommendations and resolving the conflict in the rebase. But by now this should be routine. Alice just pulls from origin/master and is up-to-date. Now, all three repositories have exactly the same changes on their respective master branches.
After these two exercises, Alice and Bob have a joint paper that they are ready to upload to the arXiv. They can tag the final commit with the identification information and revision number the arXiv assigns, they can digitally sign the tag with their GPG keys, attesting to the genuineness of the work (Section 8.4). Because the commit hashes are chained, any tampering with any of the commits will break the digital signature. The commit hash for this tag could be good information to include at the arXiv site as well.