1 of 17

Git Lesson 2: dealing with conflicts

CS 5010

“Bootcamp”

2 of 17

Learning Objectives

  • At the end of this lesson you should be able to:
    • explain what happens when you pull changes from an upstream repository
    • understand what a conflict is
    • resolve a simple merge conflict in a text file (including a .rkt file)

3 of 17

A Commit

my-project

docs

manual.docx

user_docs.docx

src

main.rkt

module1.rkt

module2.rkt

module3.rkt

.git

commit

When you do a “commit”, you record all your local changes into the mini-fs.

The mini-fs is “append-only”. Nothing is ever over-written there, so everything you ever commit can be recovered.

Remember the basic story from the preceding lesson

4 of 17

Synchronizing with the server (1)

my-project

docs

manual.docx

user_docs.docx

src

main.rkt

module1.rkt

module2.rkt

module3.rkt

.git

push

At the end of each work session, you need to save your changes on the server. This is called a “push”.

Now all your data is backed up.

  • You can retrieve it, on your machine or some other machine.
  • We can retrieve it (that’s how we collect homework)

your local machine

a server, somewhere on the internet, eg. github.com

5 of 17

Synchronizing with the server (2)

my-project

docs

manual.docx

user_docs.docx

src

main.rkt

module1.rkt

module2.rkt

module3.rkt

.git

pull

To retrieve your data from the server, you do a “pull”. A “pull” takes the data from the server and puts it both in your local mini-fs and in your ordinary files.

If your local file has changed, git will merge the changes if possible. If it can’t figure out how to the merge, you will get an error message. Dealing with this is beyond the scope of this tutorial ☹

your local machine

a server, somewhere on the internet, eg. github.com

pull

6 of 17

Now it’s time to deal with conflicts

7 of 17

Q: When might this happen?

A: When your partner committed some changes to the server, which you don't have.

Your partner's work (on the server)

Your work (on your local machine)

Your last pull

8 of 17

Result of Syncing

Your partner's work (on the server)

Your work (on your local machine)

Your changes are applied to the latest version on the server. This is called "rebasing"

Combined work now lives on both the server and your local machine.

9 of 17

Most of the time, this works well

  • So long as you and your partner are working on separate parts of the file, this works fine.
  • Both sets of changes get made, and the history on the server stays linear
  • But what happens if you and your partner commit incompatible changes?

10 of 17

What will you see?

11 of 17

So, click on tools and open a shell

Don't panic!

First, look at the file in an editor

This is what we’re going to do

12 of 17

Here's what the conflicted file looks like (in emacs)

what's on the server

what's on the local machine

13 of 17

Next: edit the file the way you want it

no more >>>'s

14 of 17

add the fixed-up file to the commit

tell git to continue to the next change

ok! we are ready to sync

if there were more conflicts, we'd have to do this process for each of them.

15 of 17

And we're ready to get back to work

Observe that both commits are now in your history

16 of 17

Summary

  • In this lesson you have learned
    • what happens when you pull changes from an upstream repository
    • what a conflict is
    • how to resolve a simple merge conflict in a text file (including a .rkt file)

17 of 17

Next Steps

  • If you have questions or comments about this lesson, post them on the Discussion Board