Resolve Git Conflicts

You are tasked with helping resolve Git merge or rebase conflicts. This command handles both active conflict states and proactive conflict preview/resolution.

Step 1: Detect Conflict State

First, determine the current state:

# Check if we're in the middle of a merge
git rev-parse --verify MERGE_HEAD 2>/dev/null && echo "MERGE_IN_PROGRESS" || echo "NO_MERGE"

# Check if we're in the middle of a rebase
test -d "$(git rev-parse --git-dir)/rebase-merge" -o -d "$(git rev-parse --git-dir)/rebase-apply" && echo "REBASE_IN_PROGRESS" || echo "NO_REBASE"

# Check for unmerged files (active conflicts)
git diff --name-only --diff-filter=U

Based on results:

• Active merge conflict: MERGE_HEAD exists + unmerged files present
• Active rebase conflict: rebase-merge/rebase-apply dir exists + unmerged files present
• No active conflict: Can preview differences for potential conflicts

Step 2: Gather Context

Get Branch Information

# Current branch
git branch --show-current

# Target branch (default: main)
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main"

# Fetch latest to ensure accurate comparison
git fetch origin

If Active Conflict Exists

# List all conflicted files AND capture the list now — once files are staged
# in Step 5, `--diff-filter=U` returns nothing. Step 7's merge commit message
# reads this file.
git diff --name-only --diff-filter=U | tee /tmp/conflicted.txt

# Show the conflict markers in each file
git diff --check

If No Active Conflict (Preview Mode)

# Show what would change when merging target into current
git diff origin/main...HEAD --name-status

# Show detailed diff
git diff origin/main...HEAD --stat

# Identify files modified in both branches (potential conflicts)
git log origin/main..HEAD --name-only --pretty=format: | sort -u > /tmp/head_files
git log HEAD..origin/main --name-only --pretty=format: | sort -u > /tmp/main_files
comm -12 /tmp/head_files /tmp/main_files

Step 3: Analyze Each Conflicted File

For each conflicted or potentially conflicting file:

3.1 Show Both Versions

# For active conflicts - show the three-way diff
git diff <file>

# Show "ours" version (current branch)
git show :2:<file>

# Show "theirs" version (incoming branch)
git show :3:<file>

# Show common ancestor
git show :1:<file>

3.2 Understand the Changes

For each file, analyze:

1. What "ours" (current branch) changed: What was the intent of changes on the current branch?
2. What "theirs" (target branch) changed: What was the intent of changes from the incoming branch?
3. Conflict type:
   • Overlapping edits: Same lines modified differently
   • Adjacent edits: Close proximity changes
   • Structural conflicts: Function/class restructuring
   • Semantic conflicts: Logic changes that may conflict conceptually

3.3 Propose Resolution Strategy

For each conflict, suggest one of:

1. Accept Ours: Keep current branch changes (theirs were superseded/duplicated)
2. Accept Theirs: Accept incoming changes (ours are outdated/wrong)
3. Merge Both: Both changes are valid and can coexist
4. Manual Resolution: Changes conflict semantically - need human decision

Step 4: Ask Clarifying Questions

When intent is ambiguous, ask specific questions:

Template Questions

For overlapping edits:

"In <file> at line X, both branches modified the same code:

• Current branch: [summary of change]
• Incoming branch: [summary of change]

Which behavior should we keep?

1. Current branch's approach
2. Incoming branch's approach
3. Combine both (explain how)
4. Need more context to decide"

For structural conflicts:

"The file <file> was restructured differently in both branches:

• Current branch: [describe restructure]
• Incoming branch: [describe restructure]

This requires manual review. Would you like me to show the full diff?"

For semantic conflicts:

"Both branches changed the logic in <function>:

• Current: [behavior description]
• Incoming: [behavior description]

These may be incompatible. Which business logic is correct?"

Step 5: Apply Resolutions

After understanding all conflicts and getting answers to questions:

For Accept Ours

git checkout --ours <file>
git add <file>

For Accept Theirs

git checkout --theirs <file>
git add <file>

For Merge Both

Edit the file to combine both changes, then:

git add <file>

For Manual Edits

After editing:

# Verify no conflict markers remain
grep -n "^<<<<<<< " <file> && echo "Still has conflict markers!" || git add <file>

Step 6: Verify Resolution

After resolving all conflicts:

# Check no unmerged files remain
git diff --name-only --diff-filter=U

# Verify no conflict markers in staged files
git diff --cached | grep -E "^[+](<<<<<<<|=======|>>>>>>>)" && echo "Warning: Conflict markers still present!"

# Show what will be committed
git diff --cached --stat

Step 7: Complete the Merge/Rebase

For Merge Conflicts

# Commit the merge, citing the conflicted-file list captured in Step 2.
# Do NOT use `git diff --name-only HEAD~1` here — that lists every merged
# file, not just the files whose conflicts were resolved.
git commit -m "Merge origin/main into $(git branch --show-current)

Resolved conflicts in:
$(cat /tmp/conflicted.txt)"

For Rebase Conflicts

# Continue the rebase
git rebase --continue

If more conflicts appear during rebase, repeat from Step 3.

Step 8: Summary

After completion, provide:

Resolution Summary

Recommendations

• If many conflicts occurred, consider more frequent rebasing/merging
• If semantic conflicts are common, consider better branch coordination
• Document any non-obvious resolution decisions for PR reviewers

Abort Options

If resolution isn't going well:

Abort Merge

git merge --abort

Abort Rebase

git rebase --abort

Tips

• Always fetch first: Ensure you have the latest remote state
• Small conflicts are easier: Merge frequently to avoid large conflicts
• Tests after resolution: Run tests to verify merged code works
• Commit message clarity: Document what conflicts were resolved and how
• When in doubt, ask: Semantic conflicts often need human judgment