How can I verify a Git conflict resolution before completing a merge?

Start by reading the entire conflicted section in the edited file, not just the lines where Git showed a conflict. Check that the result expresses the intended combination of both changes—or a deliberate choice between them—and that nearby lines still make sense. Git records unmerged versions in the index while a conflict is unresolved, and its documented resolution flow is to edit the file, add the resolved path to the index, then commit or continue the merge. [S1]

For a made-up example, suppose notes.txt conflicted. Open it in your editor and examine the surrounding paragraphs. Ask: Is there any leftover conflict text? Did I accidentally delete a heading, duplicate a sentence, or keep only one side when both changes were needed? The file is only one part of the review: next check what Git considers unresolved, then inspect the staged result.

Search the edited file for the conflict-marker text shown in it, including the opening and separator lines and any closing line. For example, a local text search could look for <<<<<<<, =======, and >>>>>>>; adapt the command to your operating system and search the file you actually edited. A match deserves inspection, but a search with no matches is not proof that the resolution is correct. A marker-like string could also be intentional text.

Then run:

git status

Look for unmerged paths. Git’s merge guidance recommends using git status to check for them before recording the merge. [S1] If Git still reports the file as unmerged, do not assume it is ready to complete. If the path is no longer listed as unmerged, that confirms Git’s conflict state has changed; it does not establish that your chosen content is semantically right. Keep the review of the file separate from the status check.

Stage the resolved path, then inspect the staged diff. In the disposable example, assuming notes.txt is the file you resolved:

git add notes.txt
git diff --cached -- notes.txt
git status

git diff --cached compares the index with HEAD and shows the staged changes that would be committed. git diff without --cached instead shows working-tree changes that have not been staged. [S2] Review the staged output line by line: check that the intended resolution is present, unrelated edits are absent, and no part of the fix was left unstaged. Use git status again to see the overall state.

Do not treat the staged diff as an automatic approval. It displays content for inspection; it does not certify that the merge is correct. If the project has relevant tests, run them before completing the merge.

When using Git’s default ort merge strategy, the merge documentation describes git diff AUTO_MERGE as a way to review textual edits made during conflict resolution. [S1] You can try it in the local example:

git diff AUTO_MERGE -- notes.txt

Treat this as an additional view, not a replacement for reading the file or reviewing what is staged. The cited guidance concerns textual conflict-resolution edits with the default ort strategy; it does not establish that this comparison applies to every merge setup or verifies semantic correctness. If the command is not relevant to your merge, use the file review, status check, and staged diff instead.

A practical stopping point is: you have read the whole resolved section, checked for leftover markers, confirmed there are no unmerged paths, and reviewed the staged diff. Then run relevant project checks if available. Only after those reviews should you choose the project’s normal way to complete the merge. These checks help you inspect the result; they cannot guarantee that it is correct.