Skip to content

Semantic Conflict

Spicy — senior dev territoryGit & Version Control

ELI5 - The Vibe Check

A semantic conflict is the scariest kind of merge because git doesn't even notice it. Two branches touch completely different lines, so the merge sails through with zero conflict markers, but one branch renamed a function and the other branch never got the memo and still calls the old name. Git's happy, the compiler is not, and you won't find out until CI, or worse, production, explodes.

Real Talk

A semantic conflict occurs when two independently merged changes are textually non overlapping and merge cleanly at the line level, but are logically incompatible, such as one branch renaming or changing the signature of a function that another branch's unmodified code still depends on. Because git's merge algorithm operates purely on text, semantic conflicts are invisible to it and can only be caught by compilation, type checking, or a test suite, which is one of the strongest arguments for running full CI on every merge rather than trusting a clean merge alone.

When You'll Hear This

"The merge was clean, but it's a semantic conflict, the tests fail because the function signature changed." / "No conflict markers doesn't mean no conflict, run the suite."

Made with passive-aggressive love by manoga.digital. Powered by Claude.