how does git handle merging code that was moved to a different file?_问答_开发者

Say I have function X in file A, and I wanted to move that function to file B. In the meantime, some开发者_Python百科body else made changes to function X in file A.

Does git do anything special when merging those two changes? Would it recognize the same function was moved to file B and apply the changes there? Or would we end up losing the changes or having two copies of the same function in file A and B?

Most of the articles I found about moving code in git refer mostly to renaming whole files and not blocks of code inside files. The closest I found is a blurb from Linus at kerneltrap:

And when using git, the whole 'keep code movement separate from changes' has an even more fundamental reason: git can track code movement (again, whether moving a whole file or just a function between files), and doing a 'git blame -C' will actually follow code movement between files. It does that by similarity analysis, but it does mean that if you both move the code and change it at the same time, git cannot see that 'oh, that function came originally from that other file', and now you get worse annotations about where code actually originated.

So it seems like git will recognize that the code was moved somewhere else, but doesn't really say what happens during a merge.

No, git won't do this level of change. It will notice when you move an entire file; so, for example, if you moved the file, deleted everything else in it, then it might stand a chance of picking up the changes. But it doesn't do a change on a per-subfile or any kind of refactoring.

I don't think the previous answer is correct in the general case, because git doesn't really care about files - the file name is used as the basis for some heuristics, but the way git thinks about content isn't centred entirely around the idea of a file. Unlike other VCSs, git tracks content, and in this case the content happens to have moved, but it's the same content.

As a result, git should be able to handle merges between branches even where files have been renamed, or code move between files, so depending on what exactly you've done, it will probably handle the merge fine.

As long as the changes to X don't cause a merge conflict (which could happen if you'd changed both the original version and the renamed version), the fact that X has been moved to B shouldn't matter, and the merge result should contain the result of both changes. If there is a problem, it would indicate that git hasn't correctly tracked the code movement.

In practice, the previous answer is probably based on personal experience when the detection machinery failed, in which case https://git.wiki.kernel.org/index.php/GitFaq#How_to_manually_resolve_conflicts_when_Git_failed_to_detect_rename.3F may be helpful.

I think AlBlue is correct, not Nye.

In my simple test, git 1.7.0.5 was not able to automatically merge two branches where one branch inserted a line into a function, and the other moved that function to a new location in the same file. git is not tracking chunks of content smaller than the file, it seems.

To resolve the merge conflict, the person doing the merge would have to be aware of how the two changes worked and how they should be combined.

See also git merge: apply changes to code that moved to a different file

I think the real situation is much more complex, but from what I have experienced, git can handle this kind of 3-way merge well.

For example:

One function of a File in branch A was moved to another location in the same file and meanwhile create a branch B to hold it. The difference between branch B and branch A is only the code location change in the same file.

Branch C changed that function.

So, if you do:

$ git rebase --onto B A C

It will automatically merge the change from branch C to the new location of that function in branch B.