A conflict is not an error. It means two commits changed the same lines and Git needs a human decision. The fear around conflicts comes from not knowing the mechanics.

Learning objectives

• Read conflict markers and resolve them.
• Complete or abort a merge safely.
• Choose between merge and rebase.
• Reduce conflicts before they happen.

1. What a conflict looks like

<<<<<<< HEAD
const price = 4999;
=======
const price = 5499;
>>>>>>> feature/new-pricing

• HEAD (or ours) is the branch you are merging into.
• The other side (theirs) is the branch being merged.

The file is now plain text with markers. Edit it to the final content, delete the three marker lines, then:

git add src/pricing.js
git commit            # completes the merge

2. During a rebase

git rebase main
# CONFLICT (content): Merge conflict in src/pricing.js

Resolve the file, then:

git add src/pricing.js
git rebase --continue

To abandon everything:

git rebase --abort
git merge --abort

Both restore the state before the operation started. When unsure, abort and look at the history with a clear head.

3. Merge or rebase?

Merge preserves the true history, including the branch shape:

A --- B --- C ------- M   main
       \            /
        D --- E ---

Rebase replays your commits on top of the target, producing a straight line:

git switch feature/pricing
git rebase main

A --- B --- C --- D' --- E'   feature/pricing

Rules:

• Rebase local, unpushed commits to keep history readable.
• Never rebase a branch someone else is working from — it rewrites commit hashes.
• Merge into shared branches; rebase your own branch before opening a PR.

4. Reading the conflict better

git status                 # which files are unmerged
git diff --name-only --diff-filter=U
git log --merge -p src/pricing.js   # commits from both sides touching the file
git checkout --ours src/pricing.js  # take one side wholesale (use carefully)
git checkout --theirs src/pricing.js

--ours and --theirs are reversed during a rebase: the branch you are rebasing onto is "ours". Verify with git status before trusting the label.

5. Preventing conflicts

• Pull main often; short branches conflict less.
• Keep formatting changes in their own commit — a reindented file conflicts with everything.
• Split work by file or module where possible.
• Agree on a formatter (Prettier) so whitespace is never the disagreement.

6. A safe resolution loop

1. git status — see what is unmerged.
2. Open each file and search for <<<<<<<.
3. Decide the final code; do not keep markers "for later".
4. Run the tests before committing the merge.
5. git add each resolved file, then continue.

Common mistakes

• Committing files that still contain conflict markers.
• Choosing "ours" or "theirs" for the whole file when both sides had valid changes.
• Rebase-aborting in a panic after pushing — check whether the branch was shared first.
• Resolving without running the build; the conflict is textual, the bug is semantic.

Practice

Create a real conflict in the assignment, resolve it twice — once with merge, once with rebase — and compare the resulting history.