Git and GitHub / Intermediate: collaborative change management / Lesson 8

Conflict resolution as semantic integration

Inspect base and side versions, choose intended behavior, and verify the resolved snapshot before continuing.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Read unmerged index stages and operation state.
Resolve content deliberately or abort a cleanly started lab operation.

A conflict marks an unresolved combination

A conflict occurs when Git cannot automatically choose a combined result under the selected operation and strategy. It is not proof that one collaborator was wrong. Both sides can contain necessary changes, or the correct result can differ from both. Determine whether the operation is merge, rebase, cherry-pick, or stash application because continuation and side labels depend on context. Begin by reading status and preserving important work. A merge started from a clean temporary tree is easier to abort than an operation mixed with unrelated local edits.

Inspect the base and both sides

For a typical content conflict during a two-branch merge, the index can store stage 1 for the base, stage 2 for the current side, and stage 3 for the other side. Some conflict types lack one stage, such as additions or deletions. The commands below read the lab versions without choosing a winner. During rebase, ours and theirs can feel reversed because commits are replayed onto a new base; do not memorize the words as permanent ownership labels. Read actual content and operation state before using side-selection shortcuts.

bash Inspect an in-progress synthetic merge conflict

git status --short
git ls-files -u -- notes.txt
git show :1:notes.txt
git show :2:notes.txt
git show :3:notes.txt

Requires a temporary lab where both branches changed the same original line in notes.txt. The stage outputs show the common base and the two differing lines. This inspection is meaningful only while that unmerged index state exists.

Choose behavior before removing markers

Conflict markers delimit alternatives in a text presentation; deleting the markers is not the complete engineering task. Read surrounding code, requirements, tests, and any schema or API assumptions. Decide whether to keep one side, combine both, or implement a new coherent result. Binary and rename conflicts need different treatment than line edits. For generated files, understand the source and regenerate through the supported tool rather than hand-editing an opaque output. Keep a note of the reasoning when the resolution changes behavior beyond either original patch, so review can evaluate the integration itself.

Stage the resolved result and continue the right operation

After editing the lab file to the intended combined content, git add tells Git the path is resolved by storing that result in the index. It does not verify the behavior. Inspect the staged patch, check whitespace and remaining unmerged paths, run relevant tests, and then continue the operation. The example completes a merge with a synthetic identity. A rebase or cherry-pick uses its own --continue interface instead. Never run a continuation blindly when status indicates a different operation or unresolved paths remain.

bash Complete the synthetic merge after deliberate resolution

printf 'Combined notebook title\n' > notes.txt
git add -- notes.txt
git diff --cached --check
git diff --name-only --diff-filter=U
git -c user.name="Lab Author" -c user.email="lab@example.invalid" commit -m "Resolve notebook title integration"

The unmerged-path command should print nothing once all lab conflicts are resolved. The commit creates the merge result only when a merge is actually in progress. This is a contextual fragment and is never applied to the workspace repository.

Abort deliberately and improve future integration

If you cannot resolve confidently, preserve useful observations and use the operation-specific abort path, such as merge --abort for a cleanly started lab merge. Restoration can be complicated by pre-existing uncommitted work, which is why preparation matters. Seek domain context instead of picking a side to make the tool quiet. Smaller coherent changes, early communication about shared interfaces, and targeted tests reduce resolution ambiguity. After completion, inspect the graph and final content and ensure no conflict markers or accidental duplicate behavior remain. A conflict-free status is only one part of a verified resolution.

Common errors and fixes

Markers are removed but behavior is broken

Why it happens: Resolution was treated as text cleanup only.
How to fix it: Re-evaluate the combined behavior and run targeted tests.
Prevent it next time: Review integration assumptions before staging.

A side shortcut selects the wrong content

Why it happens: Ours and theirs were interpreted without operation context.
How to fix it: Inspect stages and actual content before selecting.
Prevent it next time: Explain merge versus rebase side semantics in the lab.

Abort cannot reconstruct unrelated edits cleanly

Why it happens: The operation started with mixed uncommitted work.
How to fix it: Preserve current files and inspect recovery options carefully.
Prevent it next time: Start integrations from a protected, understandable state.

Check your understanding

1. Both branches add required validation to the same function. Why is choosing one entire side risky?

Show worked solution

It can silently discard the other requirement. Read the common base and both changes, construct a combined rule, and test each boundary plus their interaction. The correct resolution may be a third version.

2. A rebase stops, but a learner runs merge --abort. What should guide the next action?