Resolve a Git conflict by understanding both changes

A conflict says Git cannot choose safely. Picking “ours” or “theirs” without understanding the base can discard valid work from either branch.

Preserve both independent changes

The engineering foundations lab models a config conflict.

from engineering_cases import merge_conflict_case

result = merge_conflict_case()
assert result["base"] == {"timeout": 5, "retries": 2}
assert result["resolved"] == {"timeout": 8, "retries": 3}
assert all(result["tests"].values())
assert result["markers_remaining"] is False

One branch raises timeout; the other raises retries. The semantic resolution keeps both.

Read the base and commits that introduced each change. Identify intent, invariants and downstream callers. Edit a coherent result, remove all markers, then run targeted tests and broader checks affected by the merge. Review the staged diff as one new change.

For delete/modify or schema conflicts, contact the other author when intent is unclear. Record a decision if the resolution changes behaviour. Avoid resolving generated files directly when their source can be regenerated.

The FDE for Freshers course uses conflict resolution to teach collaborative reasoning rather than button memorization.

Exercise

Create two branches that change separate aspects of one function and one shared assertion. Merge, explain the base/ours/theirs intent and prove the final tests cover both.

Continue learning

This article is part of the FDE engineering foundations sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Git branches and pull requests for a student project.
• Continue with Linux permissions for a deployed application.

Reference: GitHub merge-conflict documentation.