重命名/移动修改后的文件后，Git 不跟踪历史记录

Question

问题:我需要更改存储库中整个目录的位置。为此，我使用 git mv，如果需要，我将包含头名称更改为当前正确的名称。问题是当我在一次提交期间采取两项行动时。在这种情况下，文件历史记录丢失(git 认为这是删除和创建新文件)。

解决方法:
如果我将这些操作拆分为单独的提交，则不会发生该问题。

问题再次出现:但是，即使我使用上述解决方案，在与 master merge 期间问题也会返回。我有义务只使用 no-ff merge 。在这种情况下，对 master 分支的新提交是由两个提交和...的更改组成的。无论如何，历史记录都没有正确跟踪。

另一个丑陋的解决方法:我可以将这些提交分别交付给 master。我无法提供不可编译的代码，但如果我将其排除在构建过程之外，它可能是可行的......但它很丑陋而且非常错误......

我想知道是否有更好的解决方案来解决这个问题。

Answer 1

如果您熟悉几乎所有其他版本控制系统 (VCS)，则可能很难理解 Git 对文件历史做了什么。

事实是 Git 没有文件历史记录。它在这里的 VCS 中可能是独一无二的(尽管我对许多更神秘的 VCS 没有经验)。它的近亲 Mercurial 确实有文件历史记录:添加到 Mercurial 的每个文件都会在 Mercurial 称为 list 的文件中分配一个唯一编号，这决定了文件的身份。如果您更改一个文件的名称——或者一个充满文件的整个目录——它们会保留它们的身份，因为这些信息存在于 list 中。

Git 完全摒弃了这个概念。 Git 根本没有文件历史记录。 Git 只有提交。

每个提交都存储一个源树的完整快照。每个提交也有一定数量的父提交，通常只有一个。这更像传统的基于提交的 VCS:可以跟踪各种提交，或查看文件历史记录。但是由于 Git 没有文件历史记录，它唯一拥有的就是提交历史记录。

为了实现git log --follow和其他有用的项目，Git 提供的不是文件历史记录，而是重命名检测。 Git 可以查看任何一个特定的提交，并将该提交与其父提交进行比较——或者对于 merge 提交，与它的所有父提交进行比较。当它进行这种比较时，它提供了检测通过该提交重命名的文件的选项:在父级中具有一个名称但在子级中具有不同名称的文件。 1

在比较两个任意提交时，Git 甚至提供这种重命名检测，而不仅仅是父子提交。运行:

git diff --find-renames $hash1 $hash2

比较两次提交，只要有“文件路径 a/b/c.txt in $hash1 肯定看起来很像文件路径 d/e/f.log in $hash2”的候选者，Git 可能会声称该文件已重命名(并且然后也许也修改了)。不过，重要的是要记住，Git 只是综合了一种将第一个文件转换为第二个文件的方法。两次提交中的两个实际文件以这种方式永久存储。它们永远无法更改:只要这些提交存在，这两个文件就会以这种方式存储在这两个提交中。这两个文件实际上根本不相关，除非您希望它们相关。 Git 通过比较它们的相似性来“寻找”重命名。给 Git 一组不同的“相似性”标准——例如，-M75%而不是 -M50% ——并且 Git 可能会选择一组不同的“足够相似”的文件。

任何提交都没有发生任何事情。他们都被时间卡住了。但是使用一组不同的“重命名阈值”值、“中断阈值”等，Git 可能会配对不同的路径名。给定 --no-renames , Git 永远不会配对不同的路径名(尽管它仍然会配对具有相同名称的文件)。

(这种动态重命名检测很重要，有时在 merge 时很重要，因为 merge 运行两个 git diff --find-rename 操作，从 merge 基础提交到正在 merge 的两个分支提示提交中的每一个。如果 Git 找到重命名，它相信如果没有找到重命名，则认为是在提示中删除了基础文件，并在提示中创建了不同的文件。您可以控制重命名阈值，但不能设置中断或复制阈值，在至少在直到今天的 Git 版本中，2.15。)

1 merge 提交的含义不太清楚，因为有多个父级:这对文件 child.txt 意味着什么？有名字p1.txt在父 #1 和 p2.txt 中在 parent #2 中？传统的 VCS 以其独特的内部编号系统来确定文件身份，在这里分配了明确的含义，但在实践中，这种含义并不总是有用的，Linus Torvalds 在这里选择完全取消这个概念，可能已经在部分 react 。