~60 minutes. Create two branches, modify the same line on each, merge, and resolve the conflict.
Goal: deliberately create a merge conflict, understand what Git's conflict markers mean, resolve the conflict by editing the file, and commit the resolution.
Estimated time: 60 minutes
Prerequisites: Lab 10.1 completed; Week 10 lecture (branches, merge, conflict markers)
Setup
Continue in ~/fnd-101/lab-10-1/my-first-repo from Lab 10.1, or start fresh:
cd ~/fnd-101/lab-10-1/my-first-repo
git status # confirm clean working tree
Part A: Create two branches
Create two branches off your current state:
git branch feature-a
git branch feature-b
Verify both branches exist: git branch -a
Part B: Modify the same line on feature-a
Switch to feature-a and edit README.md:
git switch feature-a
Open README.md and change the first line to:
# FND-101 Lab 10.1 -- updated by feature-a
Stage and commit:
git add README.md
git commit -m "feature-a: update README heading"
Part C: Modify the same line on feature-b
Switch to feature-b and make a different edit to the same line:
git switch feature-b
Open README.md. On this branch, the file is unchanged from the original (each branch starts from the same base). Change the first line to:
# FND-101 Lab 10.1 -- updated by feature-b
Stage and commit:
git add README.md
git commit -m "feature-b: update README heading"
Part D: Trigger the merge conflict
Switch back to main and merge feature-a first (no conflict; main has no divergent changes):
git switch main
git merge feature-a
git log --oneline # confirm feature-a's commit is in main now
Now merge feature-b. This WILL conflict because both feature-b and main (via feature-a) modified the same line:
git merge feature-b
Git will report a merge conflict. Run git status to see which files are in conflict.
Part E: Inspect the conflict markers
Open README.md. You will see something like:
<<<<<<< HEAD
# FND-101 Lab 10.1 -- updated by feature-a
=======
# FND-101 Lab 10.1 -- updated by feature-b
>>>>>>> feature-b
<<<<<<< HEAD: everything from here to=======is the version from your current branch (main, which merged feature-a)=======: separator>>>>>>> feature-b: everything from=======to>>>>>>>is the incoming version (feature-b)
Part F: Resolve the conflict
Edit README.md to combine or choose one version. You must:
- Remove ALL three marker lines (
<<<<<<<,=======,>>>>>>>) - Replace them with the version you want to keep
For this lab, choose a heading that shows both contributions:
# FND-101 Lab 10.1 -- merged from feature-a and feature-b
Or any other resolution that makes sense. The rule is: no marker lines remain in the file.
Stage the resolved file and complete the merge:
git add README.md
git commit -m "Merge feature-b: resolve README heading conflict"
git log --oneline --graph --all
The --graph flag shows the branch topology visually.
Expected output / artifact
lab-10-2-notes.txt with:
- The output of
git log --oneline --graph --allafter the merge - A 3-5 sentence explanation of: what caused the conflict, how you resolved it, and why you chose the resolution you did
git add lab-10-2-notes.txt
git commit -m "lab-10-2: merge conflict notes"
git push
Common pitfalls
- Forgetting to remove the markers: if
<<<<<<remains in the file, your code/text is broken. Always search the file for<<<after resolving to confirm no markers remain. - Committing during a conflict:
git commitwill fail if there are unresolved conflicts. Git checks for marker strings before allowing the commit. - "Already up to date": if you do not see a conflict when merging feature-b, check that you actually edited the SAME line in both branches. If feature-b modified a different line than feature-a, there is no conflict (Git can merge non-overlapping changes automatically).
Stretch (optional)
After the merge, use git log --all --graph --oneline to draw the branch graph. Then use git log -p README.md to see the full patch history for README.md. Note how the conflict resolution appears in the log.
Lab 10.2 v0.1.