Resolving Review Conflicts

The Hook (The "Byte-Sized" Intro)

You open your PR and see the dreaded gray badge: "This branch has conflicts that must be resolved." Don't panic. This just means someone else merged a change to main that touches the same files you changed. It's the most normal thing in team development. Fix it in 2 minutes: update your branch, resolve the conflicts, push. Done.

📖 What is Resolving Review Conflicts?

When the base branch (main) receives new commits that conflict with your PR's changes, GitHub/GitLab marks the PR as unmergeable. You need to update your branch to incorporate those new changes, resolve the conflicts, and push the result.

Conceptual Clarity

Why PR conflicts happen:

Timeline	What Happened
Monday	You branch from `main` and edit `config.js` line 5
Tuesday	Teammate merges a PR that also edits `config.js` line 5
Wednesday	Your PR now shows conflicts — both changed the same line

Two ways to resolve:

Method	Command	When to Use
Merge main in	`git merge origin/main`	Safe, preserves all history
Rebase onto main	`git rebase origin/main`	Cleaner history, needs force-push

Real-Life Analogy

PR conflicts are like two people editing the same paragraph in a shared document simultaneously. The system flags the overlap and asks one person to reconcile both versions into a final paragraph before saving.

Visual Architecture

flowchart TD PR["📋 PR has conflicts"] --> FETCH["git fetch origin"] FETCH --> CHOICE{"Strategy?"} CHOICE -->|"Merge"| MERGE["git merge origin/main"] CHOICE -->|"Rebase"| REBASE["git rebase origin/main"] MERGE --> RESOLVE["✏️ Resolve conflicts"] REBASE --> RESOLVE RESOLVE --> STAGE["git add"] STAGE --> COMPLETE["Complete merge/rebase"] COMPLETE --> PUSH["git push"] style PR fill:#2d1b1b,stroke:#e94560,color:#e94560 style PUSH fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Blocked PRs: A conflicted PR cannot be merged — it blocks your feature until resolved.
Time sensitivity: The longer you wait, the more main diverges, making resolution harder.
Your responsibility: As the PR author, resolving conflicts is your job, not the reviewer's.
Common occurrence: In active teams, this happens regularly — it's a routine skill.

Code

bash

# ─── Method 1: Merge main into your branch ───
git switch feature/user-profile
git fetch origin
git merge origin/main

# Git marks conflicted files:
# CONFLICT (content): Merge conflict in config.js

# Open the file, resolve the markers:
# <<<<<<< HEAD
# apiUrl = "/api/v2"
# =======
# apiUrl = "/api/v3"
# >>>>>>> origin/main

# After editing:
git add config.js
git commit   # Auto-generated merge commit message
git push

# ─── Method 2: Rebase onto main (cleaner) ───
git switch feature/user-profile
git fetch origin
git rebase origin/main

# Git pauses at each conflicting commit:
# CONFLICT (content): Merge conflict in config.js

# Resolve the conflict:
git add config.js
git rebase --continue
# Repeat for each conflicting commit

# Force-push (rebase rewrote history):
git push --force-with-lease

# ─── Method 3: Resolve in GitHub UI (simple conflicts) ───
# GitHub shows "Resolve conflicts" button for simple cases
# Edit directly in the browser, mark as resolved, commit

# ─── If something goes wrong: abort ───
git merge --abort     # Undo a merge attempt
git rebase --abort    # Undo a rebase attempt

Key Takeaways

PR conflicts happen when main changes the same lines your branch changed — this is normal.
Merge or rebase your branch to resolve — merge is safer, rebase is cleaner.
After resolving, push to your branch and the PR updates automatically.
Don't wait — resolve conflicts as soon as they appear.

Interview Prep

Q: Why do conflicts appear in pull requests? A: Conflicts appear when the base branch (main) receives new commits that modify the same lines your PR modifies. Git can't auto-merge the differences, so it marks the PR as conflicted and requires manual resolution.
Q: Should you merge or rebase to resolve PR conflicts? A: Either works. Merging main into your branch is safer (doesn't rewrite history) and doesn't require force-pushing. Rebasing creates a cleaner history but requires --force-with-lease to push. Teams usually standardize on one approach.
Q: What does git push --force-with-lease do after resolving conflicts with rebase? A: Since rebase rewrites commit hashes, the remote branch has different commits than your local branch. --force-with-lease overwrites the remote branch with your rebased version, but only if no one else has pushed to it in the meantime — preventing accidental data loss.