Chapter 3.1 of the the Git book明确指出，只有暂存的文件才能作为blob存储在提交树中。
如果blob像提交对象一样，获得了其内容唯一的哈希ID，那么Git如何设法跟踪跨提交的blob和文件之间的对应关系？同一文件Blob在不同提交中的哈希ID不能匹配，因为它们的内容不同。
一个简单的示例：
让我们假设我只是创建了一个没有提交的空仓库。我创建一个文件README.md，暂存并提交。 Git存储一个树对象，该树对象的Blob由README.md内容的哈希标识。
让我们修改README.md，暂存并提交。 Git存储一个树对象，该树对象的Blob由README.md的已修改内容的哈希标识。自然，我们可以期望第二个哈希与第一个提交树中标识README.md的blob的哈希不同。
Git将如何回答有关README.md历史记录的请求？
git log README.md
我的直觉是，它会遍历提交历史并比较相关的blob，但我看不出Git如何知道blob对应于同一文件的不同版本，除非是琐碎的情况。
答案 0 :(得分：12)
这实际上是一个很好的问题。
提交的内部存储形式部分相关，因此让我们考虑一下。单个提交实际上很小。这是来自Git的Git存储库中的一个，即提交b5101f929789889c2e536d915698f58d5c5c6b7a：
$ git cat-file -p b5101f929789889c2e536d915698f58d5c5c6b7a | sed 's/@/ /'
tree 3f109f9d1abd310a06dc7409176a4380f16aa5f2
parent a562a119833b7202d5c9b9069d1abb40c1f9b59a
author Junio C Hamano <gitster pobox.com> 1548795295 -0800
committer Junio C Hamano <gitster pobox.com> 1548795295 -0800
Fourth batch after 2.20
Signed-off-by: Junio C Hamano <gitster pobox.com>
（sed 's/@/ /'可能是为了减少Junio Hamano必须获得的电子邮件垃圾邮件的数量：-)）。如您在此处看到的，提交对象通过另一个提交的哈希ID a562a11983...引用其父提交对象。它还通过哈希ID引用 tree 对象，并且树对象的哈希ID以3f109f9d1a开头。我们也可以使用git cat-file -p查看这个树对象：
$ git cat-file -p 3f109f9d1a | head
100644 blob de1c8b5c77f7566d9e41949e5e397db3cc1b487c .clang-format
100644 blob 42cdc4bbfb05934bb9c3ed2fe0e0d45212c32d7a .editorconfig
100644 blob 9fa72ad4503031528e24e7c69f24ca92bcc99914 .gitattributes
040000 tree 7ba15927519648dbc42b15e61739cbf5aeebf48b .github
100644 blob 0d77ea5894274c43c4b348c8b52b8e665a1a339e .gitignore
100644 blob cbeebdab7a5e2c6afec338c3534930f569c90f63 .gitmodules
100644 blob 247a3deb7e1418f0fdcfd9719cb7f609775d2804 .mailmap
100644 blob 03c8e4c613015476fffe3f1e071c0c9d6609df0e .travis.yml
100644 blob 8c85014a0a936892f6832c68e3db646b6f9d2ea2 .tsan-suppressions
100644 blob 536e55524db72bd2acf175208aef4f3dfc148d42 COPYING
（树上有很多数据，所以我只在这里复制了前十行）。
在树中，您会看到模式（100644），类型（blob-这是模式所隐含的，也记录在内部Git对象中；实际上并没有存储在树中对象），哈希ID（de1c8b5c77f...）和Blob的名称（.clang-format）。您还可以看到tree可以引用其他tree对象，就像.github子树一样。
如果我们使用这个特定的blob对象哈希ID，我们也可以通过哈希ID查看该对象的内容：
$ git cat-file -p de1c8b5c77f | head
# This file is an example configuration for clang-format 5.0.
#
# Note that this style definition should only be understood as a hint
# for writing new code. The rules are still work-in-progress and does
# not yet exactly match the style we have in the existing code.
# Use tabs whenever we need to fill whitespace that spans at least from one tab
# stop to the next one.
#
# These settings are mirrored in .editorconfig. Keep them in sync.
（同样，由于文件很长，我已将副本截断了10行）。
仅出于说明目的，我们也来看看.github子树：
$ git cat-file -p 7ba15927519648dbc42b15e61739cbf5aeebf48b
100644 blob 64e605a02b71c51e9f59c429b28961c3152039b9 CONTRIBUTING.md
100644 blob adba13e5baf4603de72341068532e2c7d7d05f75 PULL_REQUEST_TEMPLATE.md
Git使用这些对象的作用是，根据需要以递归方式读取提交中的 tree 对象。 Git会将它们读入称为 index 或 cache 的数据结构中。 （从内存的角度来看，从技术上讲，此版本是 cache 数据结构，尽管Git文档倾向于在何时使用哪个名称上有些松懈。）因此，通过读取commit { {1}}会说，例如，名称b5101f929789889c2e536d915698f58d5c5c6b7a的模式为.clang-format和blob哈希为100644，而名称de1c8b5c77f7566d9e41949e5e397db3cc1b487c的模式为.github/CONTRIBUTING.md和blob -哈希100644。
请注意，实际上，各种名称组件（64e605a02b71c51e9f59c429b28961c3152039b9加.github）已加入内存缓存中。 （以磁盘格式，通过算法欺骗将其压缩。）
最后，它是内部（内存中）高速缓存，用于保存<文件名，文件模式，blob哈希>元组。如果您要求Git将提交CONTRIBUTING.md与其他提交进行比较，则Git还将另一个提交读入内存缓存中。另一个缓存要么有一个名为b5101f929789889c2e536d915698f58d5c5c6b7a的条目，要么没有。
如果两个提交的文件名都具有相同的名称，则Git假定（出于此比较的目的，Git现在正在做的操作，请参见下面的内容），这些文件是相同的文件。不管blob哈希是否相同，都是如此。
我们在这里回答的真正问题与身份有关。在版本控制系统中，文件的身份确定该文件在两个不同版本中是否为“同一”文件（但是版本控制系统本身定义了版本）。如this Wikipedia article on the thought experiment about the Ship of Thesus所述，这与身份的基本哲学问题有关：我们如何知道某人，甚至某些一个，我们是谁或什么？如果您在表弟鲍勃（Bob）很小的时候遇到了他，又遇到了一个名叫鲍勃（Bob）的人，他是您的表弟吗？你和他那时很小。现在您越来越大，经验也有所不同。在现实世界中，我们从环境中寻求线索：鲍勃（Bob）是父母的兄弟姐妹的孩子吗？如果是这样，即使鲍勃（和你）现在看起来很不一样，鲍勃（鲍勃）可能也是你很久以前见过的堂兄（鲍勃）。
Git当然不会做任何事情。在大多数情况下，两个文件都被命名为.github/CONTRIBUTING.md的简单事实足以将它们标识为“同一文件”。名称相同，所以就完成了。
.github/CONTRIBUTING.md提供了额外的服务在我们的日常开发中，有时有时会重命名文件。出于某种原因，名为git diff的文件可能被重命名到a/b.c或d/e.f。
假设我们正在提交d/e.c，文件名为a123456。然后，我们提交a/b.c。该第二次提交没有f789abc，但是确实有a/b.c。 Git会简单地从索引（缓存的磁盘形式）和工作树中删除d/e.f，并将新的a/b.c填充到我们的索引和工作树中，一切都很好。 / p>
但是假设我们要求Git将d/e.f与a123456进行比较。 Git 可以告诉我们：要将f789abc更改为a123456，请删除f789abc并使用这些内容创建一个新的a/b.c。 / em> {em> 是d/e.f所做的，足够了。但是，如果内容完全匹配怎么办？ Git告诉我们，效率更高：要将git checkout更改为a123456，将f789abc重命名为a/b.c。实际上，使用正确的选项，d/e.f 将做到这一点：
git diffGit如何管理这个技巧？答案在于计算文件身份。
假设提交 L （用于左侧）具有某个不在提交 R （用于右侧）中的文件（git diff --find-renames a123456 f789abc
） 。进一步假设提交 R 中有一些不在提交 L 中的文件（a/b.c）。 Git现在可以比较两个文件的内容，而不是立即告诉我们：您应该删除L文件并使用R文件。
由于Git对象散列的性质-它们完全基于文件内容而具有确定性-因此，Git检测 L d/e.f非常容易 >与 R 中的a/b.c 100％相同。在这种情况下，它们将具有完全相同的哈希ID！因此，Git会这样做：如果有一些文件从 L 中消失了，而另一些文件已出现在 R 中，则Git被要求查找重命名，Git检查哈希ID匹配。如果找到一些文件，则将这些文件配对（并将它们从不匹配文件的队列中删除-该队列中存放着 L 和 R 中的文件，是“重命名”检测队列”。
具有不同名称的那些文件已被标识为同一文件。小表弟鲍勃毕竟和大表弟鲍勃一样-除非在这种情况下，你们两个都还需要小。
因此，如果尚未 重命名检测将 L 中的文件与 R 中的文件配对，则Git会更加努力。现在，它将提取实际的斑点，并计算出一种“匹配百分比”。这使用了一个复杂的小算法，在此不再赘述，但是如果两个文件中足够的子字符串匹配，则Git会声明这些文件为50％，60％，75％或更多的 like 。
在重命名队列中发现一对文件，例如彼此相似的72％，Git继续将这些文件与所有其他文件进行比较。如果发现这两个中的一个与另一个有94％的相似性，则相似性配对优于72％的相似性配对。如果不是这样，那么72％的相似度就足够了（至少50％），因此Git会将这两个文件配对并声明它们具有相同的身份。
无论如何，如果匹配足够好并且是所有未配对文件中最好的，那么将采用该特定匹配。再一次，小堂兄鲍勃毕竟和大堂兄鲍勃一样。
在所有个不匹配的文件对上运行此测试后，d/e.f获取匹配的结果并调用这些文件重命名。同样，只有在使用git diff（或--find-renames）的情况下才会发生这种情况，并且可以根据需要将阈值设置为50％以外的值。
-M命令提供另一项服务。请注意，我们从假定开始，如果提交 L 和 R 具有相同的 name 文件，则这些文件是相同的 file ，即使内容不同。但是，如果不是这样呢？如果 L 中的git diff在 R ，和中被重命名为file，又有人创建了一个新的{{1} }在 R？
要处理此问题，bettername提供了file（或“中断配对”）选项。启用git diff时，如果名称太相似，则以名称开头的文件将失去配对。也就是说，Git将检查两个blob哈希是否匹配，否则，Git将计算相似性索引。如果索引低于 某个阈值，在运行-B样式重命名检测器之前，Git将断开配对并将两个文件放入重命名检测队列。
作为一种特殊的转折，Git将对破损的配对进行重新配对，除非它们极为相似以至于您不希望这样做。因此，对于-B，您实际上指定了两个相似度阈值：第一个数字是何时暂时断开配对，第二个数字是何时永久断开配对。
--find-renames使用-B 使用git merge执行三向合并时，有三个输入：
git diff --find-renames和git merge。 Git在内部运行两条 --ours命令。一个将碱基与 L 进行比较，另一个将碱基与 R 进行比较。
这两个差异都在启用--theirs的情况下运行。如果从base到 L 的差异找到一个重命名，则Git会知道在该重命名中使用显示的 changes 。同样，如果从base到 R 的差异找到一个重命名，则Git会知道使用这些更改。如果两个差异都显示重命名，它将结合两组更改，并尝试（但通常失败）合并两个重命名。
git diff也使用重命名检测器在使用--find-renames时，Git遍历提交历史记录，一次提交一对（父母与孩子），在父与子之间做比较。它打开有限形式的重命名检测代码，以查看您正在git log --follow进入的一个文件是否在该提交对中被重命名。如果是这样，git log --follow一旦移到父级，它就会更改要查找的名称。该技术效果很好，但是在合并时会遇到一些问题（因为合并提交有多个父项）。
文件身份就是所有这些。由于Git不知道，因此，先验，提交 L 中的文件--follow与提交 R <中的文件git log是“不是”文件/ em>，Git可以使用重命名检测来决定。在某些情况下（例如签出 L 或 R ），这一点无关紧要。在某些情况下，例如将两个提交区分开，这很重要，但仅对我们人类试图了解所发生的事情具有重要意义。但是在某些情况下（例如合并），这非常重要。
答案 1 :(得分：0)
您的意思是，如果文件已更改？好吧，文件是否已更改实际上并不重要。每个修订版都指向一个 tree ，即该修订版在该时间点表示的项目的根目录。树是一种递归结构，其中包含更多树（与根树的概念相同）或文件的名称。因此，您将获得树的名称（目录）或文件...。以及 content 的ID。如果对象是文件，则直接获取内容...如果对象是树，那么..您将获得另一棵结构和内容不同的树...以此类推。现在...每个修订都指向也，因此它的父修订（或父修订，如果是合并提交）也是如此。该修订版还包含一棵树，该树当然会及时映射到项目的内容，等等。瞧！没有技巧。
那么，如果文件更改内容会怎样？好吧....您将在组成您所讨论的修订的树的结构中拥有具有相同“名称”的树...但是ID将会更改，因为文件的内容将更改。因此，名称将相同，ID将更改。我认为您必须先使用git cat-file -p，然后再进行修订，然后再使用对象ID（树，blob），以便您完全了解发生了什么。