This course's scope: conflicts inside an open pull request

What you already know

"Git merging & conflicts" showed what a conflict is: both sides change the same lines differently, and Git refuses to guess. It also showed how to read and resolve one, editing the three markers (<<<<<<< HEAD, =======, >>>>>>> branch-name) by hand until they're gone. "GitHub pull requests" then showed the layer GitHub wraps around a plain git merge: review, comments, required checks and three merge-button strategies. Neither course asks the question this one exists to answer.

The question neither course asks

What happens when the conflict shows up on a branch that's in an open pull request, already reviewed and commented on, maybe already approved, and main moves underneath it? That's different from a solo git merge at your own terminal, and different from the clean path "GitHub pull requests" walked through. It has its own tools: a conflict editor built into GitHub's web interface, a cost for fixing it the wrong way that only shows up once a review is in progress, and a difference between resolving it as the PR's author and resolving it as someone reviewing another person's work.

An example from this repository

This repository's db/seeds.rb has been changed by 48 commits on main, most of them catalog and course edits to the same shared file. That's the kind of file that collides as soon as two people, or two branches, touch it around the same time. The count comes from this repository's git log when this course was revised.

Why this matters more once a PR is involved

A conflict at your own terminal costs you a few minutes, and nobody else notices. A conflict inside an open PR has an audience: a reviewer who already read the diff, comments attached to specific lines, maybe an approval. Resolving it carelessly can quietly undo review feedback, and resolving it well takes a different toolkit than a solo merge.

How this course is organized

Every mechanic from "Git merging & conflicts" (the markers, git status, git diff, --ours/--theirs) is assumed knowledge here. It's reused by name and not taught again.

What this course covers

1. GitHub's web-based conflict editor: what it can and can't do
2. When resolving locally is the only option, and pushing the fix back
3. What a force-push does to a review in progress
4. Reviewing someone else's conflicted pull request
5. Keeping PRs conflict-free: git rerere and small branches
6. Putting it together: a conflict on this repository's db/seeds.rb