Resolving Conflicts

Course 2 · Ch 3

Resolving Conflicts Properly

Tools that make conflicts easier to read, a real strategy for working through them, and how to abort safely when needed

Course 1, Chapter 10 introduced conflicts at the simplest level — two people, one file, manual marker editing. This chapter goes further: tools that make conflicts genuinely easier to read, a repeatable strategy for working through several at once, and what's different when a conflict happens during a rebase rather than a merge.

A Quick Recap of the Markers

<<<<<<< HEAD
your version of this section
=======
their version of this section
>>>>>>> branch-name

Everything between the markers is the disputed section — git has already merged everything else in the file automatically; only genuinely overlapping lines end up wrapped like this.

Better Ways to See a Conflict Than Reading Raw Markers

git diff during a conflict

Mid-conflict, plain git diff shows a special three-way view — useful for understanding what changed on each side before diving into the markers themselves:

$ git diff
diff --cc index.html
index a1b2c3d,9f8e7d6..0000000

VS Code's built-in conflict resolution

VS Code (and most modern editors) detect conflict markers automatically and offer inline buttons: Accept Current Change, Accept Incoming Change, Accept Both Changes, or Compare Changes in a side-by-side diff view. For most day-to-day conflicts, this is faster and less error-prone than manually editing marker text.

git mergetool

$ git mergetool

Launches a dedicated three-pane merge tool (configurable — VS Code, Meld, KDiff3, and others all work) showing "yours," "theirs," and the merged result side by side. Worth setting up if conflicts come up often enough that the inline editor view starts feeling cramped.

git status during a conflict tells you exactly which files still need attention

Mid-conflict, git status lists every file with unresolved conflicts under "Unmerged paths" — useful for tracking progress when a merge touches several files at once, so nothing gets missed before committing.

A Repeatable Conflict-Resolution Strategy

Run git status first — see the full scope

Before touching any file, know how many are conflicted. Resolving one at a time on a multi-file conflict without this context risks losing track of what's left.

Resolve the simplest files first

Building momentum on easy ones (often whitespace or formatting-only conflicts) before tackling genuinely complex logical conflicts keeps the process from feeling overwhelming.

For each file: understand BOTH sides before choosing

Don't default to "mine" or "theirs" reflexively — read what each side was actually trying to accomplish. Sometimes the correct resolution is a genuine combination of both, not a pure pick.

Stage each resolved file as you finish it

git add <file> immediately after resolving — it marks that file as done in git status, and you can see your remaining work shrink.

Test before committing the resolution

A conflict resolution that compiles/runs correctly is far more trustworthy than one that merely "looks right" — especially for logic conflicts, not just text conflicts.

Conflicts Are Slightly Different During a Rebase

Because a rebase (Chapter 2) replays commits one at a time, a conflict can occur on any of those commits individually — and you resolve them one at a time too, continuing the rebase after each.

$ git rebase main
CONFLICT (content): Merge conflict in index.html
Could not apply f1... Add hero section
# Resolve index.html, then:
$ git add index.html
$ git rebase --continue
# If another commit conflicts too, repeat the same process

🔀 Merge conflict

One conflict to resolve, then a single git commit finishes the merge.

📏 Rebase conflict

Potentially one conflict per replayed commit — resolve, git add, git rebase --continue, repeat until done.

Aborting Safely

There is never any pressure to push through a conflict resolution you're not confident about. Both merge and rebase can be cancelled completely, returning you to exactly where you were before starting.

$ # Cancel a conflicted merge entirely
$ git merge --abort

$ # Cancel a conflicted rebase entirely (including any already-resolved steps)
$ git rebase --abort

$ # Cancel a conflicted pull (which is really fetch + merge under the hood)
$ git merge --abort # same command — a pull conflict is a merge conflict

--abort fully resets, it doesn't save partial progress

If you've resolved three out of five conflicted files and then abort, all five revert to their conflicted (or pre-conflict) state — there's no partial-save. If you're confident in some resolutions but stuck on others, it's often better to commit what you've got resolved in a safe spot (or just take your time) rather than abort and lose completed work.

Command Reference

Command	What it does
git status	Lists files with unresolved conflicts under "Unmerged paths"
git diff	Shows a three-way diff view during an active conflict
git mergetool	Opens a dedicated visual merge tool for the conflicted files
git add <file>	Marks a conflict as resolved for that specific file
git rebase --continue	Proceeds to the next commit after resolving the current rebase conflict
git merge --abort	Cancels a conflicted merge (or pull) entirely, no partial save
git rebase --abort	Cancels a conflicted rebase entirely, no partial save

Chapter 3 Quick Reference

Better than raw markers: your editor's inline conflict buttons, or git mergetool for a dedicated three-pane view
Strategy: git status for scope → easiest files first → understand both sides → stage as you go → test before committing
Rebase conflicts can occur per-commit — resolve, git add, git rebase --continue, repeat
git merge --abort / git rebase --abort — fully cancel, return to the pre-conflict state, no partial save
A pull conflict is just a merge conflict — same markers, same tools, same abort command
No time pressure — aborting and asking a collaborator is always a legitimate option over guessing
Next chapter: fork workflow vs shared-repo workflow — contributing to projects you don't have direct push access to