第 8 篇 揭开面纱.pdf

第 8 章 揭开⾯纱 我们揭开Git神秘⾯纱，往⾥瞧瞧它是如何创造奇迹的。我会跳过细节。更深⼊的描 参 见 ⽤户⼿ 册。 ⼤象⽆形 数据完整性 智能 索引 Git的源起 对象数据库 Blob对象 Tree对象 Commit对象 没那么神 ⼤象⽆形 Git怎么这么谦逊寡⾔呢？除了偶尔提交和合并外，你可以如常⼯作，就像不知道版本 控 制系统存在⼀样。那就是，直到你需要它的时候，⽽且那是你欢欣的时候，Git⼀ 直默默 注视着你。 其他版本控制系统强迫你与繁⽂缛节和官僚主义不断⽃争。⽂件的权限可能是只读 的， 除⾮你显式地告诉中⼼服务器哪些⽂件你打算编辑。即使最基本的命令，随着⽤ 户数⽬ 的增多，也会慢的像爬⼀样。中⼼服务器可能正跟踪什么⼈，什么时候check out 了什么 代码。当⽹络连接断了的时候，你就遭殃了。开发⼈员不断地与这些版本 控制系统的种 种限制作⽃争。⼀旦⽹络或中⼼服务器瘫痪，⼯作就嘎然⽽⽌。 与之相反，Git简单地在你⼯作⽬录下的.git`⽬录保存你项⽬的历史。这是你⾃⼰的 历 史拷⻉，因此你可以保持离线，直到你想和他⼈沟 为⽌。你拥有你的⽂件命运 完全的 控制权，因为Git可以轻易在任何时候从.git`重建⼀个保存状态。 数据完整性 很多⼈把加密和保持信息机密关联起来，但⼀个同等重要的⽬标是保证信息安全。合 理 使⽤哈希加密功能可以防⽌⽆意或有意的数据损坏⾏为。 ⼀个SHA 1哈希值可被认为是⼀个唯⼀的160位ID数，⽤它可以唯⼀标识你⼀⽣中遇到 的每 个字节串。 实际上不⽌如此：每个字节串可供任何⼈⽤好多辈⼦。 对⼀个⽂件⽽⾔，其整体内容的哈希值可以被看作这个⽂件的唯⼀标识ID数。 因为⼀个SHA 1哈希值本⾝也是⼀个字节串，我们可以哈希包括其他哈希值的字节 串。这 个简单的观察出奇地有⽤：查看“哈希链” 。我们之后会看Git如何利⽤这⼀点 来⾼效地 保证数据完整性。 简⾔之，Git把你数据保存在.git/objects⼦⽬录，那⾥看不到正常⽂件名，相反 你只 看到ID 。通过⽤ID作为⽂件名，加上⼀些⽂件锁和时间戳技巧，Git把任意⼀个 原始的⽂ 件系统转化为⼀个⾼效⽽稳定的数据库。 智能 Git是如何知道你重命名了⼀个⽂件，即使你从来没有明确提及这个事实？当然，你或 许 是运⾏了 git mv ，但这个命令和 git add 紧接 git rm 是完全⼀样的。 Git启发式地找出相连版本之间的重命名和拷贝。实际上，它能检测⽂件之间代码块的 移 动或拷贝 ！尽管它不能覆盖所有的情况，但它已经做的很好了，并且这个功能也总 在改 进中。如果它在你那⼉不⼯作的话，可以尝试打开开销更⾼的拷贝检测选项，并 考虑升 级。 索引 为每个加⼊管理的⽂件，Git在⼀个名为“in ex”的⽂件⾥记录统计信息，诸如⼤⼩， 创建时间和最后修改时间。为了确定⽂件是否更改，Git ⽐较其当前统计信息与那些在 索 引⾥的统计信息。如果⼀致，那Git就跳过重新读⽂件。 因为统计信息的调⽤⽐读⽂件内容快的很多，如果你仅仅编辑了少数⼏个⽂件，Git⼏ 乎 不需要什么时间就能更新他们的统计信息。 我们前⾯讲过索引是⼀个中转区。为什么⼀堆⽂件的统计数据是⼀个中转区？因为添 加 命令将⽂件放到Git的数据库并更新它们的统计信息，⽽⽆参数的提交命令创建⼀ 个提交， 只基于这些统计信息和已经在数据库⾥的⽂件。 Git 的源起 这个 Linux 内核邮件列表帖⼦ 描 了导致Git 的⼀系列事件。整个讨论线索是⼀个令 ⼈着迷的历史探究过程，对Git史学家⽽⾔。 对象数据库 你数据的每个版本都保存在“对象数据库”⾥，其位于⼦⽬录.git/objects`；其他 位 于.git/` 的较少数据：索引，分⽀名，标签，配置选项，⽇志，头提交的当前位置 等。 对象数据库朴素⽽优雅，是Git的⼒量之源。 .git/objects⾥的每个⽂件是⼀个对象。有3 中对象跟我们有关：“blob”对象， “tree”对象，和“commit”对象。 Blob对象 ⾸先来⼀个⼩把戏。去⼀个⽂件名，任意⽂件名。在⼀个空⽬录： $ echo sweet YOUR_FILENAME $ git init $ git dd . $ find .git/objects -type f 你将看 到 .git/objects/