在我们的应用程序中，我们经常需要在发布分支上重命名文件/包，然后将此更改（以及许多其他更改）合并到主干。一个很大的问题是许多SCM解决方案（我们当前的SVN）不跟踪文件重命名。当我们将产品的发布分支合并回主干时，很容易丢失这些更改，因为SCM不够智能，不知道MyOriginalFileName和MyRenamedFileName是同一个文件/类/等。
在我看来，我们可能做错了什么，GIT处理这个问题的方法是什么？
答案 0 :(得分：6)
我相信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存储库。 然后你可以玩它，看看它是否满足你的需求
答案 1 :(得分：4)
我不熟悉SVN，所以我不确定你遇到的问题是什么，但是Git似乎在重命名方面做得很好。
执行重命名后，您必须确保将文件重新添加到git索引，否则它会认为您刚刚删除了旧文件而不是重命名。
如果您重命名文件并进行一些更改;也许你也重命名了一个#include文件。提交时，您会收到如下消息：
rename: MyOriginalFilename -> MyRenamedFileName (99%)
百分比表示新文件与原始文件的相似程度，因此它甚至不必是该文件内容的精确副本。
答案 2 :(得分：4)
Git不使用重命名跟踪 ，但它确实使用基于重命名检测 的启发式相似性。这意味着Git会比较/检查更改的文件并决定重命名，以及哪些文件应该在解析合并期间匹配。实际上它运作得很好。
请注意，由于重命名检测算法，如果使用过于简单的测试用例，则无法正常工作;但是在真正的合并上它应该运作良好。
答案 3 :(得分：3)
Git实际上不会将文件作为文件跟踪，而是跟踪树结构中的内容。不同之处在于，即使将块从一个文件移动到另一个文件，git也会自动识别并相应地应用合并 - 无需手动交互。
当然，只有当移动的块很大且足够独特时才会起作用，但特别是当重命名整个文件时，这就像魅力一样。
答案 4 :(得分：1)
有人可能会对 Bazaar 版本控制系统将重命名跟踪作为一项关键功能感兴趣。
甚至还有一篇来自 Mark Shuttleworth（创建 Canonical 的 Ubuntu Linux 的首席执行官）的博客文章，标题为 "Renaming is the killer app of distributed version control"（文章来自 2007 年）。这是一个 great introduction to Bazaar。
出于某种原因，Bazaar 没有流行起来，但我个人非常喜欢它。它有一个非常简单易懂的用户界面，可以跟踪重命名和空文件夹。
Bazaar 有一个名为 Breezy 的新分支，试图推动项目向前发展。这是一个关于 Breezy 的介绍性视频演示，标题为 "Breezy, a platform for experiments in version control"。