- 11.1 Clone, Push, Pull
- 11.2 Pulling and Merge Conflicts
- 11.3 Pushing Branches
- 11.4 A Surprise Bonus
- 11.5 Summary
- 11.6 Advanced Setup
- 11.7 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
11.2 Pulling and Merge Conflicts
In Section 11.1, Alice didn’t make any changes while Bob was making his commit, so there was no chance of conflict, but this is not always the case. In particular, when two collaborators edit the same file, it is possible that the changes might be irreconcilable. Git is pretty smart about merging in changes, and in general conflicts are surprisingly rare, but it’s important to be able to handle them when they occur. In this section, we’ll consider both non-conflicting and conflicting changes in turn.
11.2.1 Non-conflicting Changes
We’ll start by having Alice and Bob make non-conflicting changes in the same file. Suppose Alice decides to change the top-level heading on the About page from “About” to “About Us”, as shown in Listing 11.2.
Listing 11.2: Alice’s change to the About page’s h1.
~/repos/website/about.html
After making this change, Alice commits and pushes as usual:
[website (main)]$ git commit -am "Change page heading" [website (main)]$ git push
Meanwhile, Bob decides to add a new image (Figure 11.11)4 to the About page. He first downloads it with curl as follows:
)
Figure 11.11: An image for Bob to add to the About page.
[website-copy (main)]$ curl -o images/polar_bear.jpg > -L https://cdn.learnenough.com/polar_bear.jpg
(As noted in Section 10.1, you should type the backslash character \ but you shouldn’t type the literal angle bracket >.) He then adds it to about.html using the img tag, as shown in Listing 11.3, with the result shown in Figure 11.12.
)
Figure 11.12: The About page with an added image.
Listing 11.3: Adding an image to the About page.
~/tmp/website-copy/about.html
Note that Bob has included an alt attribute in Listing 11.3, which is a text alternative to the image. The alt attribute is actually required by the HTML5 standard, and including it is a good practice because it’s used by web spiders and by screen readers for the visually impaired.
Having made his change, Bob commits as usual:
[website-copy (main)]$ git add -A [website-copy (main)]$ git commit -m "Add an image"
When he tries to push, though, something unexpected happens, as shown in Listing 11.4.
Listing 11.4: Bob’s push, rejected.
Because of the changes Alice already pushed, Git won’t let Bob’s push go through: As indicated by the first highlighted line in Listing 11.4, the push was rejected by GitHub. As indicated by the second highlighted line, the solution to this is for Bob to pull:
[website-copy (main)]$ git pull
Even though Alice made changes to about.html, there is no conflict because Git figures out how to combine the diffs. In particular, git pull brings in the changes from the remote repo and uses merge to combine them automatically, adding the option to add a commit message by dropping Bob into the default editor, which on most systems is Vim (Figure 11.13). (This is just one of many reasons why Learn Enough Text Editor to Be Dangerous (https://www.learnenough.com/text-editor) covers Minimum Viable Vim (Section 5.1).) To get the merge to go through, you can simply quit out of Vim using :q.
)
Figure 11.13: The default editor for merging from a git pull.
We can confirm that this worked by checking the log, which shows both the merge commit and Alice’s commit from the original copy (Listing 11.5).
Listing 11.5: The Git log after Bob merges in Alice’s changes. (Exact results will differ.)
If Bob now pushes, it should go through as expected:
$ git push
This puts Bob’s changes on the remote repo, which means Alice can pull them in:
$ git pull
Alice can confirm that her repo now includes Bob’s changes by inspecting the Git log, which should match the results you got in Listing 11.5. Meanwhile, she can refresh her browser to see Bob’s cool new ursine addition (Figure 11.14).
11.2.2 Conflicting Changes
Even though Git’s merge algorithms can often figure out how to combine changes from different collaborators, sometimes there’s no avoiding a conflict. For example, suppose both Alice and Bob notice that the required alt attribute is missing from the whale image included in Listing 10.1 and decide to correct the issue by adding one.
)
Figure 11.14: Confirming that Alice’s repo includes Bob’s added image.
First, Alice adds the alt attribute “Breaching whale” (Listing 11.6).
Listing 11.6: Alice’s image alt.
~/repos/website/index.html
She then commits and pushes her change:5
[website (main)]$ git commit -am "Add necessary image alt" [website (main)]$ git push
Listing 11.7: Bob’s image alt.
~/tmp/website-copy/index.html
Meanwhile, Bob adds his own alt attribute, “Whale” (Listing 11.7), and commits his change:
[website-copy (main)]$ git commit -am "Add an alt attribute"
If Bob tries to push, he’ll be met with the same rejection message shown in Listing 11.4, which means he should pull—but that comes at a cost:
[website-copy (main)]$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0 Unpacking objects: 100% (3/3), 415 bytes | 207.00 KiB/s, done. From https://github.com/mhartl/website 679afb8..81c190a main -> origin/main Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. [website-copy (main|MERGING)]$
As indicated in the second highlighted line, Git has detected a merge conflict from Bob’s pull, and his working copy has been put into a special branch state called main|MERGING.
Bob can see the effect of this conflict by viewing index.html in his text editor, as shown in Figure 11.15. Supposing Bob prefers Alice’s more descriptive alt text, he can resolve the conflict by deleting all but the line with alt=”Breaching whale”, as seen in Figure 11.16. (In fact, as seen in Figure 11.15, Atom includes two “Use me” buttons to make it easy to pick one of the options. Clicking on the bottom “Use me” button gives the same result shown in Figure 11.16.)
)
Figure 11.15: A file with a merge conflict.
)
Figure 11.16: The HTML file edited to remove the merge conflict.
After saving the file, Bob can commit his change, which causes the prompt to revert back to displaying the main branch, and at that point he’s ready to push:
[website-copy (main|MERGING)]$ git commit -am "Use longer alt attribute" [website-copy (main)]$ git push
Alice’s and Bob’s repos now have the same content, but it’s still a good idea for Alice to pull in Bob’s merge commit:
[website (main)]$ git pull
Because of the potential for conflict, it’s a good idea to do a git pull before making any changes on a project with multiple collaborators (or even just being edited by the same person on different machines). Even then, on a long enough timeline some conflicts are inevitable, and with the techniques in this section you’re now in a position to handle them.
11.2.3 Exercises
Change your default Git editor from Vim to Atom. Hint: Google for it. (This is an absolutely classic application of technical sophistication (Box 8.2): With a well-chosen Google search, you can often go from “I have no idea how to do this” to “It’s done” in under 30 seconds.)
The polar bear picture added in Listing 11.3 (Figure 11.11) requires attribution under the Creative Commons Attribution 2.0 Generic license. As Alice, link the image to the original attribution page, as shown in Listing 11.8. Then run git commit -a without including -m and a command-line message. This should drop you into the default Git editor. Quit the editor without including a message, which cancels the commit.
Run git commit -a again, but this time add the commit message “Add polar bear attribution link”. Then hit return a couple of times and add a longer message of your choice. (One example appears in Figure 11.17.) Save the message and exit the editor.
Figure 11.17: Adding a longer message in a text editor.
Run git log to confirm that both the short and longer messages correctly appear. After pushing the changes to GitHub, navigate to the page for the commit to confirm that both the short and longer messages correctly appear.
As Bob, pull in the changes to the About page. Verify by refreshing the browser and by running git log -p that Bob’s repo has been properly updated.
)