Git如何在重构期间跟踪历史记录？

Question

我很清楚Git如何支持文件移动:因为它使用文件哈希,"添加"文件很容易被检测为与"删除"文件相同.

我的问题是关于重构:考虑到Java,包声明会发生变化,因此文件内容将不相同.在这种情况下,Git如何确定"添加"文件与"已删除"文件共享历史记录？它是否检查"最相似的内容",假设我只做了一些小改动,或类似的非确定性解决方案？

Answer 1

如Git FAQ中所述,它将基于启发式检测类似内容.

Git必须与许多不同的工作流互操作,例如,某些更改可能来自补丁,其中重命名信息可能不可用.依赖显式重命名跟踪使得无法合并两个完全相同的树,除了一个做了补丁(创建/删除),一个做了它使用其他启发式.

在第二个注释中,跟踪重命名实际上只是跟踪内容在树中移动的特殊情况.在某些情况下,您可能会对添加函数或将其移动到其他文件时的查询感兴趣.只需依靠在需要时重新创建此信息的能力,Git旨在提供一种更灵活的方式来跟踪树木的变化情况.

但是,这并不意味着Git不支持重命名.
Git中的diff机制支持自动检测重命名,这是通过' -M'切换到git-diff-*命令族来打开的.
重命名检测机制由git-log(1)和git-whatchanged(1)使用,因此,例如,' git log -M'将为提交历史记录提供重命名信息.
Git还支持有限形式的重命名合并.
这两个工具表示谴责,git-blame(1)并git-annotate(1)都使用了自动重命名检测代码跟踪重命名.

git log 为您提供有关该启发式的一些详细信息:

-B[<n>][/<m>]

将完整的重写更改分为删除和创建对.这有两个目的:

• 它影响了一个更改的方式,相当于一个文件的完全重写,而不是一系列的删除和插入混合在一起,只有几行恰好与文本作为上下文匹配,而是作为单个删除所有旧的后跟一个单个插入所有新内容,数字m控制-B选项的这个方面(默认为60%).
  -B/70%指定少于30%的原始内容应保留在结果中,以便git将其视为完全重写(即,否则生成的修补程序将是一系列删除和插入与上下文行混合在一起).

• 与-M一起使用时,完全重写的文件也被视为重命名源(通常-M只考虑作为重命名源消失的文件),而数字n控制-B选项的这一方面(默认为50%).
  -B20%指定添加和删除的更改与文件大小的20%或更多相比有资格被选为可能的重命名源到另一个文件.

-M[<n>]

如果生成差异,则检测并报告每次提交的重命名.对于在遍历历史记录时重命名后续文件,请参阅--follow.
如果指定了n,则a是相似性指数的阈值(即与文件大小相比的添加/删除量).
例如,-M90%表示如果超过90%的文件未更改,git应将删除/添加对视为重命名.

其他参考:

• Linus的终极内容跟踪工具博客文章,由Git的维护者Junio C Hamano撰写.
• 让Git确认先前移动的文件
• 如何将git标记为已删除的文件并将新文件作为文件移动？
• Git如何解决合并问题？

注意:使用Git 2.18(2018年第二季度),git status现在应该显示移动/重命名文件时重命名(而不是删除/添加文件).
请参阅" 如何告诉Git它是同一个目录,只是一个不同的名称 ".