Conflict Resolution in Rebase vs Merge

Rebase vs Merge: Conflict Differences

Understanding the difference between conflicts during git merge and git rebase is crucial because the same file can produce different conflict patterns depending on which operation you use. More importantly, the meaning of "ours" and "theirs" is reversed during rebase.

During git merge

git checkout main
git merge feature

• Ours = main (the branch you are on)
• Theirs = feature (the branch being merged in)
• You resolve conflicts once for the entire merge.

During git rebase

git checkout feature
git rebase main

• Ours = main (the branch being rebased onto) — this is the SWAP!
• Theirs = feature (your commits being replayed)
• You may have to resolve conflicts multiple times — once per commit being replayed.

Why the Swap Happens

During rebase, Git replays each of your commits on top of the target branch. For each replay, it treats the target branch as the "current" state (ours) and your commit as the incoming change (theirs). This is the opposite of what most developers intuitively expect.

Sequential Conflicts in Rebase

If your branch has five commits, and three of them conflict, you will resolve conflicts three separate times during the rebase. After resolving each one, you run git rebase --continue to proceed to the next commit.

Practical Implications

Scenario	Recommended approach
Short-lived feature branch, few commits	Rebase onto main for clean history
Long-lived branch, many conflicts expected	Merge to avoid repeated resolution
Shared branch with multiple contributors	Merge (never rebase shared branches)
Clean up before PR review	Interactive rebase, then merge

Abort and Retry

If you get confused during a rebase, you can always git rebase --abort to return to the original state and try again. During a merge, use git merge --abort.