How to resolve merge conflicts effectively

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Resolve merge conflicts by first understanding both sides of the change, using a three-way diff tool to compare ancestor, ours, and theirs, then making a deliberate editorial decision. In Java codebases, the most common conflicts occur in import blocks, dependency files (pom.xml/build.gradle), and auto-generated sources. Automated pre-merge practices — rebasing frequently and keeping PRs small — reduce conflict frequency dramatically.

Interview Answer2 min

A merge conflict means two branches modified the same code in incompatible ways. The instinct to immediately edit conflict markers is the wrong first move — understanding why both sides touched the same code tells you which changes should survive.

Understanding the conflict before editing

Run git log --merge before touching conflict markers to see which commits on each side modified the conflicting files — a conflict in a service class often means two features changed the same method, and blindly picking one side silently deletes the other
Three-way merge tools (IntelliJ's merge dialog, VS Code's diff editor) show the common ancestor alongside both branches — resolving hunks individually is safer than picking entire sides wholesale
For pom.xml conflicts, always resolve manually — take the union of both additions and verify compatibility against Maven Central; automated tools often discard one team's dependency silently

After resolving — verification before committing

Run mvn compile immediately after resolving Java file conflicts — stray conflict markers cause cryptic parse errors, and broken imports from duplicate lines fail compilation before they waste test time
Run the full test suite before pushing the resolution — a conflict resolution that compiles but breaks tests has introduced a regression under the appearance of a clean merge
Use git diff HEAD to review what the final resolved state looks like as a whole before committing — conflicts in multiple files can interact in non-obvious ways

Prevention — the best conflict is the one that never happens

Rebase onto main daily during active development to minimize divergence; PRs under 400 lines conflict far less often than large PRs
Enforce consistent import ordering via Checkstyle or Spotless so the formatter never produces spurious diffs in import blocks that cause false conflicts
Communicate intent before making large structural refactors — a team-wide rename or package reorganization should be a coordinated commit, not a PR that collides with everyone else's work

Interview-ready guide

Interview answer

Understanding the conflict before editing

Run git log --merge before touching conflict markers to see which commits on each side modified the conflicting files — a conflict in a service class often means two features changed the same method, and blindly picking one side silently deletes the other
Three-way merge tools (IntelliJ's merge dialog, VS Code's diff editor) show the common ancestor alongside both branches — resolving hunks individually is safer than picking entire sides wholesale
For pom.xml conflicts, always resolve manually — take the union of both additions and verify compatibility against Maven Central; automated tools often discard one team's dependency silently

After resolving — verification before committing

Run mvn compile immediately after resolving Java file conflicts — stray conflict markers cause cryptic parse errors, and broken imports from duplicate lines fail compilation before they waste test time
Run the full test suite before pushing the resolution — a conflict resolution that compiles but breaks tests has introduced a regression under the appearance of a clean merge
Use git diff HEAD to review what the final resolved state looks like as a whole before committing — conflicts in multiple files can interact in non-obvious ways

Prevention — the best conflict is the one that never happens

Rebase onto main daily during active development to minimize divergence; PRs under 400 lines conflict far less often than large PRs
Enforce consistent import ordering via Checkstyle or Spotless so the formatter never produces spurious diffs in import blocks that cause false conflicts
Communicate intent before making large structural refactors — a team-wide rename or package reorganization should be a coordinated commit, not a PR that collides with everyone else's work

03 · Deep dive