Git Merge Conflict Resolution
Trigger Boundary
- •Use when merge operations produce textual or semantic conflicts.
- •Do not use for product-level requirement prioritization; use
requirement-prioritization. - •Do not use for post-incident rollback strategy; use
git-revert-recovery.
Goal
Resolve conflicts deterministically while preserving both correctness and intent.
Shared Git Contract (Canonical)
- •Use
../git-branch-strategy/references/git-governance-contract.mdas the single schema and gate source. - •Track conflict resolution artifacts with
GIT-MRG-*IDs. - •Run machine validation:
python3 ../git-branch-strategy/scripts/validate_git_contract.py --manifest <path/to/manifest.json>.
Inputs
- •Conflicted files and conflict markers
- •Intent of each conflicting change set
- •Required tests and verification scope
Outputs
- •
GIT-MRG-*conflict resolution record - •File-level intent mapping for resolved hunks
- •Verification evidence for resolved behavior
Workflow
- •Classify conflicts by domain and behavioral impact.
- •Compare both sides' intent before editing conflict regions.
- •Resolve conflicts with minimal unintended side effects.
- •Re-run targeted and regression tests for affected paths.
- •Publish resolution record with contract validation evidence.
Quality Gates
- •Every resolved conflict has a clear intent rationale.
- •No conflict markers remain in tracked files.
- •Affected tests pass after conflict resolution.
- •History rewrite policy and branch protections remain compliant.
Failure Handling
- •Stop when conflict intent cannot be reconstructed reliably.
- •Escalate when semantic conflicts require domain-owner arbitration.