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

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 217 views

This error occurs during a Git merge or rebase when a file was renamed in one branch but deleted in another. Git cannot automatically resolve this conflict because it involves a structural change to the file tree, not just content differences. You must manually decide whether to keep the renamed file or accept the deletion.

Quick fix

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

CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but deleted in branch
  1. Understand the conflict message
  2. Option 1: Keep the renamed file
  3. Option 2: Accept the deletion
  4. Complete the merge
git — error
CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but deleted in branch
CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but deleted in branch

What this error means

The "CONFLICT (rename/delete)" message indicates that Git detected a file was renamed in one branch (typically HEAD/your current branch) while the same original file was deleted in the branch you're trying to merge. This is a tree-level conflict rather than a content conflict. Git's rename detection identified that the file was moved or renamed (based on content similarity), but since the other branch removed the original file entirely, Git cannot automatically determine what you intended. The conflict essentially asks: "Should this file exist with its new name, or should it be gone?" This type of conflict commonly occurs when: - One developer refactors and renames files while another removes obsolete code - A file is moved to a new location in one branch while considered unnecessary in another - Concurrent cleanup efforts result in one branch renaming for organization and another deleting for simplification

Typical symptoms

  • Git merge or rebase shows 'CONFLICT (rename/delete)' message
  • The message indicates a file was renamed in HEAD but deleted in the other branch
  • git status shows the file as 'deleted by them' or 'deleted by us'
  • The renamed file may appear in your working directory with changes staged
  • Merge cannot complete automatically and requires manual resolution
  • Running git diff shows unusual output for the affected files

Common causes

  1. A file was renamed or moved in one branch while deleted in another branch
  2. Two developers worked on the same file - one refactored/renamed it while another removed it
  3. A feature branch renamed a file that was deleted as obsolete in the main branch
  4. Git's rename detection (based on content similarity) matched a rename where the original was deleted
  5. Reorganization of project structure in one branch conflicted with cleanup in another
  6. Moving files to new directories while another branch removes the entire module

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

1Understand the conflict message

When you see:

bash
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:

bash
git status

You'll see something like:

bash
Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
        deleted by them: newfile.txt
2Option 1: Keep the renamed file

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

bash
# 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:

bash
git status

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

3Option 2: Accept the deletion

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

bash
# 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:

bash
git status

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

4Complete the merge

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

bash
git commit

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

bash
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.

5Handle reverse scenario (deleted in HEAD, renamed in theirs)

Sometimes the conflict is reversed:

bash
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:

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

To confirm the deletion:

bash
git rm newfile.txt

Then complete the merge with git commit.

6Use git checkout for specific versions

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

Keep your version (the renamed file):

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

Accept their version (deletion):

bash
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

7Abort the merge if needed

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

bash
git merge --abort

For a rebase conflict:

bash
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

8Prevent future conflicts with coordination

To avoid rename/delete conflicts:

Before major refactoring:

bash
# 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:

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

Review incoming changes before merging:

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

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

Advanced notes

Understanding Git's rename detection

Git doesn't explicitly track renames. Instead, it detects renames by comparing file content similarity. By default, Git considers files with >50% similar content as renames. You can adjust this:

bash
# Set rename threshold to 70% similarity
git merge -X rename-threshold=70 feature-branch

# Disable rename detection entirely
git merge -X no-renames feature-branch

Using git show to understand the conflict

View what each branch did to the file:

bash
# See the state of the file in HEAD
git show HEAD:newfile.txt

# See if the file existed in the merge base
git show $(git merge-base HEAD feature-branch):file.txt

Applying patches for complex renames

When you have changes in the deleted file that need to be applied to the renamed location:

bash
# Generate a patch from the deleted file's changes
git show MERGE_HEAD -- file.txt > changes.patch

# Apply to the renamed file (with manual adjustment if needed)
patch newfile.txt < changes.patch

The REBASE_HEAD trick

During rebases, you can apply changes from the conflicting commit to renamed files:

bash
git show REBASE_HEAD path/to/old-file.txt | patch path/to/new-file.txt

Git rerere for repeated conflicts

If you encounter the same rename/delete conflicts repeatedly, enable rerere:

bash
git config --global rerere.enabled true

Git will remember your resolutions and apply them automatically next time.

Merge strategies for structural conflicts

Consider using the recursive strategy with specific options:

bash
# Favor your changes in conflicts
git merge -X ours feature-branch

# Favor their changes in conflicts
git merge -X theirs feature-branch

Note: These options apply to conflicting hunks, not the entire file. For rename/delete conflicts, you still need to manually decide using git add or git rm.

Frequently asked questions

What does "CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but" mean?
The "CONFLICT (rename/delete)" message indicates that Git detected a file was renamed in one branch (typically HEAD/your current branch) while the same original file was deleted in the branch you're trying to merge. This is a tree-level conflict rather than a content conflict. Git's rename detection identified that the file was moved or renamed (based on content similarity), but since the other branch removed the original file entirely, Git cannot automatically determine what you intended.
How do I fix "CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but"?
This error occurs during a Git merge or rebase when a file was renamed in one branch but deleted in another. Git cannot automatically resolve this conflict because it involves a structural change to the file tree, not just content differences. You must manually decide whether to keep the renamed file or accept the deletion.
What causes "CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but"?
A file was renamed or moved in one branch while deleted in another branch Two developers worked on the same file - one refactored/renamed it while another removed it A feature branch renamed a file that was deleted as obsolete in the main branch
Is the "CONFLICT (rename/delete): file.txt renamed to newfile.txt in HEAD, but" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading