Intermediate Data Science

Merge Conflicts, On Purpose

Author

Joanna Bieri
DATA201

Intermediate Data Science

Important Information

Day 3 - Merge Conflicts, On Purpose

Today we are going to break something on purpose. You and a teammate will both change the same line of the same file, and then we will watch git complain about it and fix it together.

A merge conflict happens when git finds two different changes to the same lines of a file and can not guess which one you want. It is not an error. It is git asking you a question. The goal today is that the first time this happens to you by accident (probably during Exam 1, when your whole team is editing the same notebook) you recognize it right away and know what to do.

This should take about 20 minutes. Work with one partner from your team. Everything today happens in your team repo, not your sandbox.

Step 1 - Both partners get caught up

Both of you, in your team repo, start the way every week starts. Get on your own branch and make sure it has everything from main:

git checkout main
git pull origin main
git checkout your_branch_name
git merge main

If git refuses because of unsaved work, commit what you have first (git add -A then git commit -m "save my work") and try again.

Step 2 - Both partners edit the same line

Partner A: make a new file called Week02/conflict_practice.md. Put exactly one line in it:

FAVORITE PLOT: histogram

Partner B: make the same file, Week02/conflict_practice.md, with the same one line, but a different answer:

FAVORITE PLOT: scatter plot

Do not coordinate. That is the point.

Now both of you commit and push, on your own branch:

git add Week02
git commit -m "my favorite plot"
git push -u origin your_branch_name

Step 3 - Open two Pull Requests

Both of you go to GitHub and open a Pull Request from your branch into main.

Partner A merges first. That one goes through with no problem, because main did not have this file yet.

Partner B’s Pull Request now says there is a conflict. GitHub will not let it merge. This is the moment we are here for. Do not click any of GitHub’s “resolve” buttons, we are going to do it in the terminal so you see what actually happened.

Step 4 - Partner B looks at the conflict

Partner B, bring the new main (which now has Partner A’s file) into your branch:

git checkout main
git pull origin main
git checkout your_branch_name
git merge main

Git will say something like CONFLICT (add/add): Merge conflict in Week02/conflict_practice.md. Open that file. It looks like this:

<<<<<<< HEAD
FAVORITE PLOT: scatter plot
=======
FAVORITE PLOT: histogram
>>>>>>> main

Here is how to read it:

  • HEAD is always the branch you are standing on. Everything between <<<<<<< HEAD and ======= is yours.
  • Everything between ======= and >>>>>>> main is what came in from main, which is Partner A’s version.

Git is not confused. It found two answers and is handing you the decision, because only a person can make it.

Step 5 - Fix it together

Do this as a pair. Partner B types, Partner A watches.

  1. Decide. Keep one answer, keep both, or write something new. Your call.

  2. Edit the file. Delete all three marker lines (<<<<<<<, =======, >>>>>>>) and leave only the text you want. Save it.

  3. Stage and commit the fix:

     git add Week02/conflict_practice.md
 git commit -m "resolve favorite plot conflict"

  4. Push:

     git push origin your_branch_name

Go back to the Pull Request on GitHub. The conflict warning is gone and it merges clean.

You Try

Now switch roles and do it again, faster. Partner B creates a new file, Week02/favorite_dataset.md, Partner A creates the same file with a different line, and this time Partner B merges first so Partner A gets the conflict.

Challenge (optional) - Instead of a new file, both of you edit the same line of the existing Week02/conflict_practice.md. Does the conflict look any different? (Hint: look at what git calls it. Last time it said add/add.)

Discussion

Talk about these with your partner, then we will go over them as a class:

  1. In your own words, what do the three marker lines mean?
  2. What would have avoided this conflict completely?
  3. Was it as scary as you expected?

One more thing to know. This drill used a plain text file, so the conflict was small and easy to read. If two people edit the same notebook cell you will get the same markers, but inside the notebook’s JSON, and it is a lot uglier. Two rules keep that manageable: run nbstripout --install in each repo (once), so saved outputs do not get dragged into the conflict, and when it does happen, git checkout upstream/main -- <the file> in your sandbox or a quick conversation with your teammate in the team repo is almost always the fastest way out.