What's a good strategy for merging heavily diverged branches including renamed and moved files in git?

Question

I've got a git project with two diverged branches I want to combine into a new branch. Both branches contain a lot of changes since they split:

While one branch mainly adds many new files and also modifies existing files, the other branch mainly removed many files, renamed and moved existing files and also widely refactored their content.

I am not very experienced with advanced merging and when I tried a merge, git did not recognise the file renaming/moving but rather listed deleted/created files. Furthermore, in the many conflicting lines the changes had arised over many commits so I was often not able to understand the changes and find the relevant parts.

Is there a good merging strategy for this scenario with many changes between two branches including renamed/moved files?

Thank you!

Answer 1

Assume changes made on two branches as below:

• master: adds many new files and also modifies existing files.
• develop: removed many files, renamed and moved existing files and also widely refactored their content.

In order to resolve merge conflicts automatically and keep the renamed files, you can merge the two branches by below commands:

git checkout develop
git merge master -X theirs

Then these files will be added without conflicts:

• Files added on master branch
• Files modified on master and develop branch
• Files renamed on develop branch
• File deleted on develop branch while not modified on master branch

There only has one situation which need to resolve merge conflicts manually is:

• Files both deleted on develop branch and modified on master branch

So if there has merge conflict when you merging the two branches, you just need to use below commands to keep the files (deleted on develop branch while modified on master branch) as the version on master branch:

git add .
git commit

So all the files (added, modified and deleted) are kept after merging.

Answer 2

Unfortunately, you are in for a long slog...

First, a bit of clarification

git doesn't track file moves - it detects them.

It does so by inspecting the contents of files that were removed against files that were added to identify if the file has moved. This inspection has limits and is all too easy for it to miss. The best way to help git understand what is happening is to move the file in a commit without changes and then make the changes is a separate commit. Since it sounds like you have a long series of changes without having done this you will likely have to live with it.

When working with two branches

It is important to periodically rebase (or merge, if you must, but I will just refer to rebasing from here on) the changes committed to the branch you aren't working on into your own so it is up-to-date on the changes in the other branch.

Typically, there is a master branch and a wip branch (work-in-progress, or whatever you call it). The changes on master would be periodically rebased into wip, and when finished with wip rebased the changes back into `master.

In this way the branches never drift too far apart.

What you need to do

From your description, the branches were allowed to drift too far apart for comfort. To fix this, all that is needed is to walk the commits of one branch and rebase them into the other. This can be done manually or git rebase --interactive will walk you thru, one commit at a time, until your finished.

If your not familiar with git rebase, I suggest you read up on it since it excels at handling issues like this.

I don't recommend it, but this can be handled with git merge -- but it won't walk the commits for you and trying to handle all of the changes at once is likely going to be pain (as you described). If you want to merge the branch in pieces you will either have to handle each commit individually or (if possible) group them together -- but grouping may require intimate knowledge of what is in the commits.

References

git rebase documentation

Rebasing section of the git book