How to fix CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but deleted in branch in Git

When you see:

CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but deleted in branch

This means:
- In HEAD (your current branch): file.txt was renamed to newfile.txt
- In the incoming branch: file.txt was deleted

Git is asking you to decide: keep newfile.txt or accept the deletion?

Check the current state:

git status

You'll see something like:

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
        deleted by them: newfile.txt

If you want to keep the file with its new name, stage it with git add:

# Keep the renamed file
git add newfile.txt

This tells Git: "I want to keep this file with its new name, ignoring the deletion from the other branch."

After staging, verify the resolution:

git status

You should see the file listed under "Changes to be committed" rather than "Unmerged paths".

If you agree that the file should be deleted, use git rm:

# Accept the deletion
git rm newfile.txt

This tells Git: "I agree the file should be removed, the rename in my branch was a mistake or is now obsolete."

Verify the resolution:

git status

The file should now appear as deleted and staged for commit.

After resolving the conflict (either keeping or deleting), complete the merge:

git commit

Git will open your editor with a merge commit message. You can add a note about how you resolved the conflict:

Merge branch 'feature' into main

Resolved rename/delete conflict:
- Kept newfile.txt (renamed from file.txt)

Save and close the editor to finalize the merge.

Sometimes the conflict is reversed:

CONFLICT (rename/delete): file.txt deleted in HEAD and renamed to newfile.txt in branch

This means you deleted the file, but the incoming branch renamed it.

To keep the renamed file from the incoming branch:

git checkout --theirs newfile.txt
git add newfile.txt

To confirm the deletion:

git rm newfile.txt

Then complete the merge with git commit.

For more control, you can use git checkout with --ours or --theirs:

Keep your version (the renamed file):

git checkout --ours newfile.txt
git add newfile.txt

Accept their version (deletion):

git rm newfile.txt

Note: The meaning of "ours" and "theirs" can be confusing during rebases, where they are reversed. During a rebase:
- --ours refers to the branch being rebased onto
- --theirs refers to your commits being replayed

If you're unsure or want to start over, you can abort the merge:

git merge --abort

For a rebase conflict:

git rebase --abort

This returns your repository to the state before the merge/rebase began, allowing you to:
- Communicate with your team about the conflict
- Rename the file in your branch to match the other branch first
- Plan a better merge strategy

To avoid rename/delete conflicts:

Before major refactoring:

# Pull latest changes first
git fetch origin
git merge origin/main

Communicate structural changes to your team when:
- Renaming files or directories
- Deleting files or modules
- Reorganizing project structure

Keep branches short-lived to minimize divergence:

# Regularly sync with main
git fetch origin
git rebase origin/main

Review incoming changes before merging:

git fetch origin
git log HEAD..origin/main --name-status

This shows what files changed in the incoming branch, helping you anticipate conflicts.