git merge conflict due to renaming in two branches - how to fix & avoid in future?

Question

I have two local branches master and dev. Both branches contained three folders:

projectBeta
project
project_v1

I wanted to just keep projectBeta and remove project and project_v1 and then rename projectBeta as project. So that's what I did separately on both branches, committing as I went along. All looked good until I tried to then merge the dev branch to master, and I got a pile of these kinds of errors:

CONFLICT (rename/delete): Rename projectBeta/test.c->project/test.c in dev and deleted in HEAD
CONFLICT (rename/delete): Rename project_v1/test.c->project/test.c in HEAD and deleted in dev

So it looks like Git tracked the renames in different ways in the different branches.

If I do a git status, I get

# On branch master
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   added by us:        project/test.c
#
no changes added to commit (use "git add" and/or "git commit -a")

First thing I don't understand is why the status just says that it's "added by us" when the merge report says it's renamed and deleted by both us and them?

Secondly, I want to use the dev branch version (them) of test.c, but now when I try

git co --theirs project/test.c

I get

error: path 'project/test.c' does not have their version

...so I don't know how to ensure the merge will use the content from the dev branch?

Finally, is there a best-practice way to avoid such a mess like this in the future? Basically, changing folder structures independently in branches where the content is not ready to merge first...

Answer 1

What you need is git mv and git rm.

My guess is you probably rm'd the directories without letting git know. You must let git know because it keeps track of all the folders and needs to know how to deal with them correctly.

What you should do is:

git rm -r project
git rm -r project_v1
git mv projectBeta project