如何在git中重命名其他人正在处理的文件而不丢失历史记录？ [英] How to rename files in git that are being worked on by other people without losing history?

问题描述

在Java中，文件的名称与类的名称相关联。重命名重命名两个。

事情是，每当我这样做，坏事发生。历史迷失。发生合并冲突。人们疯狂。

如何在git中重命名文件并处理可能由此产生的任何合并冲突？

1. 历史记录附加到提交，而不是文件。


2. 提交记录状态，而不是更改。
   
   

   第一项意味着历史永远不会丢失，它只是神秘。这不是很有帮助，但 git log --follow （作为 CodeWizard写道在他的回答）通常会做这项工作（尽管 - 跟着有一些失败）。

   
   
   

   第二项的一个结果是，git不跟踪目录操作，如文件重命名。这意味着在合并操作期间（无论是从 git merge ，还是从 git rebase 或 git cherry-pick 或 git revert 或其他），git必须猜测哪些文件被命名为

   。
   
   
   

   Git的猜测是基于它的相似索引，其计算是有点复杂。这里的主要保证是一个与它以前的版本完全相同的文件将被检测为重命名。

   
   
   

   这个本身并不够用，因为Git在 git merge 或 git rebase 或其他什么，并且重命名（按比特相同的内容）可能被埋在历史中。例如，假设提交C0创建文件，C1将其修改一些，C2将其重命名，C3再次修改它。如果你说服git比较C1和C2，它会发现重命名 - 但在合并操作时，git比较C0和C3，并且如果文件不够相似，git会错过重命名。

   
   
   

   （我们可以修改Git，使其遍历从C0到C3的血统路径上的所有提交，以查找重命名，只要您将重命名单独提交，就可以完全解决此问题从计算角度讲，这会有些昂贵，但对未来版本的Git来说可能是一个好主意，当然，它现在也不会帮助你，还有另一个工具，

   >
   

   TL; DR答案：尝试将重命名提交为独立提交

   
   
   

   或者至少，如果您进行其他更改，则将其更改为其他文件。保持重命名的文件尽可能相似（比特位相同=保证重命名检测，其他任何=相似性索引发挥作用）。
   
   

   这只有在那些合并知道如何说服Git做正确的合并。在最糟糕的情况下，三次合并应该有所斩获：一次是重命名，一次是重命名，另一次是从重命名到最后。如果未来的Git版本提供祖先路径重命名检测，将来使用它。与此同时，只有重命名的提交功能才算完美。

   
   

   In Java the name of a file is tied to the name of a class. Renaming one renames both.

   The thing is, whenever I do this, bad things happen. History gets lost. Merge conflicts occur. People freak out.

   How do I rename a file in git and handle whatever merge conflicts may arise from it?

   解决方案

   In Git:

   1. History is attached to commits, not to files.
   2. Commits record a state, not a change.

   The first item means that history is never lost, it's just cryptic. Which is not really much help, but git log --follow (as CodeWizard wrote in his answer) usually does the job (though --follow has some failings).

   One consequence of the second item is that git does not keep track of directory operations like file renames. This means that during merge operations (whether from git merge, or from git rebase or git cherry-pick or git revert or whatever), git must guess which files were named what.

   Git's guesses are based on its similarity index, whose computation is a bit complex. Your main guarantee here is that a file that is bit-for-bit identical to its previous version will be detected as a rename.

   This is not necessarily enough by itself, because Git fires up the merge machinery later, at the time of the git merge or git rebase or whatever, and the rename (with bit-for-bit identical contents) may be buried in the history. For instance, suppose commit C0 creates the file, C1 modifies it some, C2 renames it, and C3 modifies it again. If you convince git to compare C1 vs C2, it finds the rename—but at the time of the merge operation, git compares C0 against C3, and if the file is not sufficiently similar, git misses the rename.

   (We could modify Git so that it iterates through all the commits on the ancestry path from C0 to C3 looking for renames, which would solve this problem completely as long as you commit the rename as a separate operation. This would be somewhat expensive, computationally speaking, but is probably a good idea for some future version of Git. Of course, it also does not help you right now. There is another tool, git-imerge, available today that can help.)

   TL;DR answer: try to commit the rename as a standalone commit

   Or at least, if you make other changes, make them to other files. Keep the renamed file as similar as possible (bit-for-bit identical = guaranteed rename detection, anything else = similarity index comes into play).

   This only helps if those merging know how to convince Git to do the right merges. In the worst case, three merges should do the trick: one up to the point of the rename, one to bring in the rename, and one from there to the end. If a future Git version offers an ancestry-path-rename-detect, use that in the future. Meanwhile the rename-only commit is as good as it gets.

   这篇关于如何在git中重命名其他人正在处理的文件而不丢失历史记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！