如果 GIT 不跟踪文件重命名，我们如何避免在合并中丢失这些更改？

Question

在我们的应用程序中，我们经常需要重命名发布分支上的文件/包，然后将此更改（以及许多其他更改）合并到主干中。 一个大问题是许多 SCM 解决方案（我们目前是 SVN）不跟踪文件重命名。 当我们将产品的发布分支合并回主干时，很容易丢失这些更改，因为 SCM 不够智能，无法知道 MyOriginalFileName 和 MyRenamedFileName 是相同的文件/类/等。

在我看来，我们可能做错了什么，GIT 处理这个问题的方法是什么？

Answer 1

我相信 Git 可以跟踪这一点。

作为一个例子，我创建了一个测试 git 存储库，我在其中添加了一个名为 test.txt 的文件并提交了它。

然后我重命名了该文件并提交了我的更改。

这是我提交的 git 日志：

[master cf5c827] test
1 files changed, 0 insertions(+), 0 deletions(-)
rename test.txt => test_renamed.txt (100%)

我的建议是使用git-svn从您的 svn 存储库创建一个 git 存储库。 然后你可以玩它，看看它是否满足你的需求

Answer 2

我不熟悉 SVN，所以我不确定您遇到的问题是什么，但 Git 似乎在重命名方面做得很好。

重命名后，您必须确保将文件重新添加到 git 索引，否则它会认为您只是删除了旧文件而不是重命名它。

如果您重命名文件并进行一些更改； 也许您也重命名了 #include 文件之一。 当您提交时，您将收到如下消息：

rename: MyOriginalFilename -> MyRenamedFileName (99%)

百分比表示新文件与原始文件的相似程度，因此它甚至不必是该文件内容的精确副本。

Answer 3

Git 不使用重命名跟踪，但它使用基于启发式相似性的重命名检测。 这意味着 Git 会比较/检查更改的文件并决定重命名，以及在解析合并期间哪些文件应该与哪些文件匹配。 实际上，它工作得很好。

请注意，由于重命名检测算法，如果您使用太简单的测试用例，它将无法正常工作； 但在真正的合并中它应该运行良好。

Answer 4

Git 实际上并不将文件作为文件进行跟踪，而是跟踪树结构中的内容。 不同之处在于，即使将块从一个文件移动到另一个 git 也会自动识别并相应地应用合并 - 无需手动交互。

当然，这仅在移动的块足够大且足够独特时才有效，但尤其是在重命名整个文件时，这就像一个魅力。

Answer 5

有人可能会对Bazaar版本控制系统将重命名跟踪作为一项关键功能感兴趣。

甚至还有来自Mark Shuttleworth （创建Ubuntu Linux的Canonical首席执行官）的博客文章，标题为“重命名是分布式版本控制的杀手级应用” （文章来自 2007 年）。 这是对 Bazaar的精彩介绍。

出于某种原因，Bazaar 没有流行起来，但我个人非常喜欢它。 它有一个非常简单易懂的用户界面，可以跟踪重命名和空文件夹。

Bazaar 有一个名为Breezy的新分支，试图推动项目向前发展。 这是一个关于 Breezy 的介绍性视频演示，标题为“Breezy，一个版本控制实验平台” 。