Introduction

When git pull creates conflicts, there are cases where you intentionally want remote changes to win. This is common for generated files, stale local experiments, or emergency synchronization with a protected branch. The important part is choosing the right command for hunk-level preference versus full branch replacement, and keeping recovery options available.

Inspect Divergence Before Resolving

Start by understanding what you are about to keep or discard.

1git status
2git fetch origin
3git log --oneline HEAD..origin/main
4git log --oneline origin/main..HEAD

This quick inspection prevents accidental loss of local commits that still matter.

Option 1: Prefer Remote Only in Conflicting Hunks

If you want to keep local non-conflicting changes but take remote where conflicts occur, merge with -X theirs.

git fetch origin
git merge -X theirs origin/main

Important detail: -X theirs does not replace every file. It only affects conflict hunks during the merge.

Option 2: Resolve Specific Files with Remote Version

If pull already failed and you want remote content for selected files, resolve file by file.

1git checkout --theirs path/to/file1
2git checkout --theirs path/to/file2
3git add path/to/file1 path/to/file2
4git commit -m "Resolve conflicts by taking remote versions for selected files"

This gives precise control and leaves room for mixed strategies across different files.

Option 3: Make Local Branch Match Remote Exactly

If local work should be discarded entirely, reset to remote tip.

git fetch origin
git branch backup-before-reset
git reset --hard origin/main

Always create a backup branch before reset. It gives an easy recovery path with almost no cost.

Rebase Pull Workflows

If your team uses rebase pull, conflict flow is different.

git pull --rebase

When conflict resolution becomes messy:

git rebase --abort

Then use explicit fetch and either merge strategy or reset strategy. Avoid mixing unresolved rebase state with ad hoc merge attempts.

Recovery with Reflog

If you accidentally discarded useful local changes, reflog usually still has them.

git reflog -n 20
git checkout -b recovered-work <sha-from-reflog>

This is why it is still safe to use destructive commands when done with a deliberate backup and quick verification.

Team-Safe Resolution Workflow

A consistent runbook reduces mistakes in high-pressure situations.

1git fetch origin
2git branch backup-conflict-$(date +%Y%m%d%H%M%S)
3git merge -X theirs origin/main
4git status
5git diff --stat HEAD~1..HEAD

Follow this with tests before push. Conflict resolution can compile yet still break behavior.

Validate Before Push

After resolving conflicts with remote preference:

• run project tests
• inspect changed files
• verify branch history looks expected

git status
git log --oneline --decorate -n 5
# run tests for your project

If branch is shared, communicate that remote-preferred conflict resolution was used so reviewers know what to inspect.

CI and Protected Branch Considerations

For protected branches, direct pushes may be blocked. In that case:

1. resolve in feature branch
2. push branch
3. open pull request with clear explanation

Document why remote-preferred resolution was required, especially if local commits were dropped intentionally.

Common Pitfalls

• Assuming -X theirs means full remote file replacement.
• Running reset --hard without creating a backup reference.
• Skipping tests after conflict resolution.
• Mixing unresolved rebase state with merge commands.
• Force pushing shared branches without team communication.

Summary

• Choose method by scope: conflict-hunk preference, file-level choice, or full reset.
• Use merge -X theirs when only conflict regions should prefer remote.
• Use checkout --theirs for targeted per-file resolutions.
• Use hard reset only when local changes are intentionally discarded.
• Keep every destructive step reversible with backups and reflog awareness.