Question

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

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

如何在git中重命名文件并处理可能出现的任何合并冲突？

Answer 1

在Git中：

历史记录附加到提交，而不是文件。
提交记录状态，而不记录更改。

第一项意味着历史永远不会丢失，它只是神秘。哪个帮助不大，但是git log --follow（因为CodeWizard wrote in his answer）通常会完成这项工作（尽管--follow有一些失误）。

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

Git的猜测基于其相似性指数，whose computation is a bit complex。这里的主要保证是，与其先前版本一点一点的文件将被检测为重命名。

这本身并不足够，因为Git会在git merge或git rebase或其他任何时候启动合并机制，并重命名（逐位相同）内容）可能被埋没在历史中。例如，假设提交C0创建文件，C1修改它，C2重命名它，C3再次修改它。如果你说服git比较C1和C2，它会找到重命名 - 但是在合并操作时，git会将C0与C3进行比较，如果文件不够相似，git会错过重命名。

（我们可以修改Git，以便它迭代通过从C0到C3的祖先路径上的所有提交寻找重命名，只要你将重命名作为一个单独的操作提交就可以完全解决这个问题。这有点像昂贵的，从计算上来说，但对于Git的未来版本来说可能是一个好主意。当然，它现在也没有帮助。现在还有另一种工具，git-imerge，可以提供帮助。）

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

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

这只有在合并知道如何说服Git进行正确的合并时才有用。在最糟糕的情况下，三个合并应该做的伎俩：一个到重命名点，一个用于重命名，一个从那里到最后。如果未来的Git版本提供了ancestry-path-rename-detect，请在将来使用它。与此同时，仅重命名的提交就像它一样好。

Answer 2

使用git rm

使用git mv重命名文件后，您可以使用git log --follow <path>

查看文件的历史记录

# Rename the desired files
git mv <old path> <new path>

# Add and commit your changes
git add .
git commit ...

# To view the history of the modified files use
git log --follow <path>

如何重命名git中正在被其他人处理的文件而不丢失历史记录？

2 个答案:

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