Code10x
Branching and mergingmedium3-5 years

A pull request that's been open for three weeks suddenly has conflicts across six files, even though the author only touched two of them. A teammate says "just rebase and force-push, that'll clear it up." What's the actual mechanism behind conflicts growing over time, and why does rebasing onto main help?

A merge conflict is never really a two-file comparison; it's decided against a third point, the merge base — the nearest commit both branches share, found by walking each branch's parent pointers backward until they meet. The longer a branch sits before merging, the further back in history that shared point is, because main keeps moving forward while the branch stands still — which means the three-way diff has to reconcile a growing amount of both histories at once, not just the two files the author actually touched. Files the author never edited can still conflict if main changed something nearby that no longer applies cleanly against the branch's now-stale starting point. Rebasing onto main moves the branch's merge base forward to main's current tip, which shrinks exactly the region the three-way diff has to reconcile — often turning a wide, multi-file conflict into no conflict at all, or a much smaller one.

The lesson behind it →
PreviousA merge fails with `CONFLICT (content): Merge conflict in config.txt`, and the file has three lines. A developer assumes the whole file is now in question and starts rewriting it from scratch. What does Git actually mean by a conflict here, and what's the right way to read the markers?Next During an interactive rebase, a developer hits a conflict, looks at the `<<<<<<< HEAD` block, and — out of habit from resolving merge conflicts — keeps that side every time. The result quietly discards their own work. What went wrong?
More on Branching and merging
A merge fails with `CONFLICT (content): Merge conflict in config.txt`, and the file has three lines. A developer assumes the whole file is now in question and starts rewriting it from scratch. What does Git actually mean by a conflict here, and what's the right way to read the markers?During an interactive rebase, a developer hits a conflict, looks at the `<<<<<<< HEAD` block, and — out of habit from resolving merge conflicts — keeps that side every time. The result quietly discards their own work. What went wrong?A developer rebases their own feature branch and pushes with `git push --force-with-lease`, expecting it to refuse if a colleague pushed to the same branch in the meantime. It doesn't refuse, and the colleague's commit is gone from the remote. What went wrong with the safety it's supposed to provide?