Moved files into folders in master. Now branches have merge conflicts

Question

Our project has too many files. So on the master branch, I moved the files into folders and now it looks clean. However when I merged master into all the other branches (so they have the latest updates), they have merge conflicts that I don't understand what they mean or how to fix them.

In master, files were moved. And in the branches, those files could have many modifications.

How can I merge master into the different branches while preserving everyone's changes?

Here's what Github desktop allows me to do, but I don't know what these options mean:

Answer 1

"moving" a file in git is equal to delete a file and add a file. So, basically, they are two distinct actions.

Of course now you have tons of conflict, as you were expecting.

My suggestion is: don't use GitHub. Do it locally, use proper time and space to do it. What you did is a refactor of the folder tree of your software, and it costs a lot in terms of work.

What happened? The new master has a deletion for file X. File X is modified in the branches as well. So the conflict is: do you want to keep the edited file or delete it? You probably want to keep it, then move it again.

Can you solve it automatically? Yes. Either writing your own keep and move script, or by trying an alternative approach: rebasing the branch on top of the new master commit. Git is smart, sometimes. There is a little chance that this way it will be able to automatically sort the issue. Be prepare to spend some manual work on this.

Answer 2

You seem to imagine that movement of a file is a "thing" in git, and that the branches you merge to are going to somehow magically "acquire" this movement as a feature, without anything else happening, or "folding" it into whatever else has happened. That is not true; that's not what git is. Git thinks in terms of individual files, and an individual file is a single path .

So file.txt is a file. If you move it to folder/file.txt , that's a different file. Git sees one file disappear and a new file appear. Git will try to connect these two files to one another if the situation is sufficiently simple, but there are no guarantees. And even if it does, it doesn't see this as a "move"; it sees it as a rename .

So I'm imagining that something like this happened:

on master:

     file file.txt moved to [was renamed as] myfolder/file.txt

on branch:

     file file.txt modified in place

So, that's a conflict. One branch renamed the file, the other branch modified the file. Git doesn't know what you want to do, so it leaves it up to you.

But you do not have a simple viable way forward either. You've done a Bad Thing. Which of those two things do you want, the rename or the modification? Neither! You want the contents of the file at file.txt in branch , but you want them in the place where the "same" file is in master , namely myfolder/file.txt . Yipes!

How are you going to fix this mess? The simplest way is to back out the merge and start over. You have two main choices:

• Do your rearrangement work on the branch(es). In other words, call up everyone on the team and say, "Hey, everybody, in whatever branch you are working on, do a commit, move file.txt to myfolder/file.txt , and do another commit." If everyone does the same thing, it will all merge into master successfully.

• Hold off entirely on the rearrangement. Call up everyone and say, "Hey everybody, when you get done with this branch, stop work until everybody has merged." Wait until everyone has merged, then do the rearrangement. Now everyone can pull master and work can start again with new branches.