这些版本控制系统如何处理重命名操作?
我发现很多矛盾的信息声称git跟踪代码行数而不是文件,因此对于它来说,重命名将没有意义。
这些版本控制系统如何处理重命名操作?
我发现很多矛盾的信息声称git跟踪代码行数而不是文件,因此对于它来说,重命名将没有意义。
hg mv
明确告诉hg有关重命名操作,或者使用hg addremove --similarity
进行自动发现。目前已经有一些讨论,考虑在合并操作中添加启发式方法。Git与其他版本控制系统不同,它没有进行重命名跟踪,这意味着它不需要通过SCM命令告知重命名操作(或运行自动检测脚本标记重命名操作并在提交前记录),也不会将此类信息保存在仓库中,而是进行重命名检测。这意味着它使用基于文件名和文件内容相似性的启发式算法来查找重命名操作,在合并过程中以及当请求使用-M
选项(或使用diff.renames
配置选项进行配置)时进行差异对比。
这种方法的优点如下:
请注意,路径模式过滤与重命名检测不兼容;如果要跟踪文件在重命名操作中的历史,请使用“git log --follow <filename>
”。
git log --follow xyz
,而明天,在 xyz
之间没有任何人更改的情况下,结果可能会有所不同。 - j_random_hacker实际上:
Git会自动检测重命名。(顺便说一句,我听说git可以检测您将一个函数从一个文件移动到另一个文件的情况。我的初步测试似乎表明这不是事实。)
对于Mercurial,您必须明确告诉它有关重命名的信息,可以通过hg mv
或hg addremove
的--similarity
选项,或TortoiseHg的"猜测重命名"选项,或某些工具(例如VisualHg)将为您标记重命名。如果您想使用Git方法来处理Mercurial中的重命名,我编写了一个扩展程序,在提交时检测重命名, 但目前处于非常试验阶段。
Subversion根本不处理重命名。它记录重命名为一个文件被删除和另一个文件被添加。这意味着,例如,如果Alice更改了一个文件而Bob重命名了它,则会出现树冲突。无论您是进行全面的分支和合并还是仅进行svn update
,都会发生这种情况。 Subversion 1.8计划增加重命名跟踪功能,预计在明年发布。
Git跟踪内容,而不是文件。我不确定Mercurial如何处理,但SVN需要明确告知重命名操作。