zh_cn/secrets.txt

   1 == 揭开面纱 ==
   2
   3 我们揭开Git神秘面纱，往里瞧瞧它是如何创造奇迹的。我会跳过细节，若要更深入的了解Git
   4 工作原理，可参见 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[ 用
   5 户手册]。
   6
   7 === 大象无形 ===
   8
   9 Git怎么这么谦逊寡言呢？除了偶尔提交和合并外，你可以如常工作，就像不知道版本控
  10 制系统存在一样。那就是，直到你需要它，并且感到时间合适的时候以外，Git都只是默
  11 默在后台看顾着你。
  12
  13 其他版本控制系统强迫你与繁文缛节和官僚主义不断斗争。文件的权限可能是只读的，
  14 除非你明确地告诉中心服务器哪些文件你打算编辑。即使最基本的命令，随着用户数目
  15 的增多，也会慢的像爬一样。中心服务器可能正跟踪什么人，什么时候check out了什么
  16 代码。当网络连接断了的时候，你就遭殃了。开发人员不断地与这些版本控制系统的种
  17 种限制作斗争。一旦网络或中心服务器瘫痪，工作就嘎然而止。
  18
  19 与之相反，Git简单地在你工作目录下的`.git`目录保存你项目的历史。这是你自己的历
  20 史拷贝，因此你可以保持离线，直到你想和他人沟通为止。你拥有你的文件命运完全的
  21 控制权，因为Git可以轻易在任何时候从`.git`重建一个曾经保存过的状态。
  22
  23 === 数据完整性 ===
  24
  25 很多人把加密和保持信息机密关联起来，但一个同等重要的目标是保证信息安全。合理
  26 使用哈希加密功能可以防止无意或有意的数据损坏行为。
  27
  28 一个SHA1哈希值可被认为是一个唯一的160位ID数，用它可以唯一标识你一生中遇到的每
  29 个字节串。 实际上不止如此：每个字节串可供任何人用好多辈子。
  30
  31 对一个文件而言，其整体内容的哈希值可以被看作这个文件的唯一标识ID数。
  32
  33 因为一个SHA1哈希值本身也是一个字节串，我们可以哈希包括其他哈希值的字节串。这
  34 个简单的观察出奇地有用：查看“哈希链”。我们之后会看Git如何利用这一点来高效地
  35 保证数据完整性。
  36
  37 简言之，Git把数据保存在`.git/objects`子目录，那里看不到正常文件名，相反你只
  38 看到ID。通过用ID作为文件名，加上一些文件锁和时间戳技巧，Git把任意一个原始的文
  39 件系统转化为一个高效而稳定的数据库。
  40
  41 === 智能 ===
  42
  43 Git是如何知道你重命名了一个文件，即使你从来没有明确提及这个事实？当然，你或许
  44 是运行了 *git mv* ，但这个命令和 *git add* 紧随 *git rm* 是完全一样的。
  45
  46 Git启发式地找出相连版本之间的重命名和拷贝。实际上，它能检测文件之间代码块的移
  47 动或拷贝！尽管它不能覆盖所有的情况，但它已经做的很好了，并且这个功能也总在改
  48 进中。如果它在你那儿不工作的话，可以尝试打开开销更高的拷贝检测选项，并考虑升
  49 级。
  50
  51 === 索引 ===
  52
  53 对每个加入库中管理的文件，Git都会在一个名为“index”的文件里记录统计信息，诸如
  54 大小，创建时间和最后修改时间。为了确定文件是否被更改，Git会将当前统计信息同那
  55 些在索引里的统计信息对比。如果一致，那Git就跳过该文件。
  56
  57 因为统计信息的调用比读文件内容快的很多，如果你仅仅编辑了少数几个文件，Git几乎
  58 不需要什么时间就能更新他们的统计信息。
  59
  60 我们前面讲过索引是一个中转区。为什么一堆文件的统计数据是一个中转区？因为添加
  61 命令将文件放到Git的数据库并更新它们的统计信息，而无参数的提交命令将只基于统计
  62 信息和已经在数据库里的文件来创建一个全新的提交。
  63
  64 === Git的源起 ===
  65
  66 这个 http://lkml.org/lkml/2005/4/6/121[ Linux内核邮件列表帖子] 描述了导致
  67 Git诞生的一系列事件。对Git史学家而言，整个讨论线是一个令人着迷的历史探究过程。
  68
  69 === 对象数据库 ===
  70
  71 你数据的每个版本都保存在“对象数据库”里，其位于子目录`.git/objects`内；其他位
  72 于`.git/`的较少数据：索引，分支名，标签，配置选项，日志，头提交的当前位置等。
  73 对象数据库朴素而优雅，是Git的力量之源。
  74
  75 `.git/objects`里的每个文件是一个对象。有3种对象跟我们有关：“blob”对象，
  76 “tree”对象，和“commit”对象。
  77
  78 === Blob对象 ===
  79
  80 首先来一个小把戏。选择一个文件名，任意文件名。在一个空目录：
  81
  82  $ echo sweet > YOUR_FILENAME
  83  $ git init
  84  $ git add .
  85  $ find .git/objects -type f
  86
  87 你将看到 +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+ 。
  88
  89 我如何在不知道文件名的情况下知道这个？这是因为以下内容的SHA1哈希值：
  90
  91  "blob" SP "6" NUL "sweet" LF
  92
  93 是 aa823728ea7d592acc69b36875a482cdf3fd5c8d，这里SP是一个空格，NUL是一
  94 个0字节，LF是一个换行符。你可以验证这一点，键入：
  95
  96   $ printf "blob 6\000sweet\n" | sha1sum
  97
  98 Git基于“内容寻址”：文件并不按它们的文件名存储，而是按它们包含内容的哈希值，
  99 在一个叫“blob对象”的文件里。我们可以把文件内容的哈希值看作一个唯一ID，这样
 100 在某种意义上我们通过他们内容放置文件。开始的“blob 6”只是一个包含对象类型与
 101 其长度的头；它简化了内部存储。
 102
 103 这样我可以轻易预言你所看到的输出：文件名是无关的：只有里面的内容被用作构
 104 建blob对象。
 105
 106 你可能想知道对相同的文件会发生什么。试图填加一个你文件的拷贝，什么文件名都行。
 107 在 +.git/objects+ 的内容保持不变，不管你加了多少。Git都只存储一次数据。
 108
 109 顺便说一句，在 +.git/objects+ 里的文件用zlib压缩，因此你不应该直接查看他们。
 110 可以通过http://www.zlib.net/zpipe.c[zpipe -d] 管道， 或者键入：
 111
 112  $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d
 113
 114 这样可以漂亮地打印出给定的对象。注意，上面的cat-file命令中，aa是目录名。
 115
 116 === Tree对象 ===
 117
 118 但文件名在哪？它们必定在某个阶段保存在某个地方。Git在提交时得到文件名：
 119
 120  $ git commit  # 输入一些信息。
 121  $ find .git/objects -type f
 122
 123 你应看到3个对象。这次我不能告诉你这两个新文件是什么，因为它部分依赖你选择的文
 124 件名。我继续进行，假设你选了``rose''。如果你没有，你可以重写历史以让它看起来
 125 像似你做了：
 126
 127  $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose'
 128  $ find .git/objects -type f
 129
 130 现在你应看到文件 +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+ ，因
 131 为这是以下内容的SHA1哈希值：
 132
 133  "tree" SP "32" NUL "100644 rose" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d
 134
 135 通过键入以下命令来检查这个文件真的包含上面内容：
 136
 137  $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch
 138
 139 使用zpipe，验证哈希值是容易的：
 140
 141  $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum
 142
 143 与查看文件相比，哈希值验证更轻巧一些，因为其输出不包含原始未压缩文件。
 144
 145 这里的输出是一个“tree”对象：一组包含文件类型，文件名和哈希值的数据。在我们的例
 146 子里，文件类型是100644，这意味着“rose”是一个一般文件，并且哈希值指blob对象，
 147 包含“rose”的内容。其他可能文件类型有可执行，链接或者目录。在最后一个例子里，
 148 哈希值指向一个tree对象。
 149
 150 在一些过渡性的分支，你会有一些你不再需要的老的对象，尽管在宽限过期之后，它们
 151 会被自动清除，现在我们还是将其删除，以使我们比较容易跟上这个示范的例子。
 152
 153  $ rm -r .git/refs/original
 154  $ git reflog expire --expire=now --all
 155  $ git prune
 156
 157 在真实项目里你通常应该避免像这样的命令，因为你在破坏备份。如果你期望一个干净
 158 的仓库，通常最好做一个新的克隆。还有，直接操作 +.git+ 时一定要小心：如果
 159 Git命令同时也在运行会怎样，或者突然停电？一般，引用应由 *git update-ref -d*
 160 删除，尽管通常手工删除 +refs/original+ 也是安全的。
 161
 162 === Commit对象 ===
 163
 164 我们已经解释了三个对象中的两个。第三个是“commit”对象。其内容依赖于提交信息
 165 以及其创建的日期和时间。为满足这里我们所需的，我们不得不调整一下：
 166
 167  $ git commit --amend -m Shakespeare  # 改提交信息
 168  $ git filter-branch --env-filter 'export
 169      GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
 170      GIT_AUTHOR_NAME="Alice"
 171      GIT_AUTHOR_EMAIL="alice@example.com"
 172      GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
 173      GIT_COMMITTER_NAME="Bob"
 174      GIT_COMMITTER_EMAIL="bob@example.com"'  # Rig timestamps and authors.
 175  $ find .git/objects -type f
 176
 177 你现在应看到 +.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+ 是下列
 178 内容的SHA1哈希值：
 179
 180  "commit 158" NUL
 181  "tree 05b217bb859794d08bb9e4f7f04cbda4b207fbe9" LF
 182  "author Alice <alice@example.com> 1234567890 -0800" LF
 183  "committer Bob <bob@example.com> 1234567890 -0800" LF
 184  LF
 185  "Shakespeare" LF
 186
 187 和前面一样，你可以运行zpipe或者cat-file来自己看。
 188
 189 这是第一个提交，因此没有父提交，但之后的提交将总有至少一行，指定一个父提交。
 190
 191 === 没那么神 ===
 192
 193 Git的秘密似乎太简单。看起来似乎你可以整合几个shell脚本，加几行C代码来弄起来，
 194 也就几个小时的事：一个基本文件操作和SHA1哈希化的混杂，用锁文件装饰一下，文件
 195 同步保证健壮性。实际上，这准确描述了Git的最早期版本。尽管如此，除了巧妙地打包
 196 以节省空间，巧妙地索引以省时间，我们现在知道Git如何灵巧地改造文件系统，使其成
 197 为一个完美的版本控制数据库。
 198
 199 例如，如果对象数据库里的任何一个文件由于硬盘错误损毁，那么其哈希值将不再匹配，
 200 这个错误会报告给我们。通过哈希化其他对象的哈希值，我们在所有层面维护数据完整
 201 性。Commit对象是原子性的，也就是说，一个提交永远不会部分地记录变更：在我们已经
 202 存储所有关于tree对象，blob对象和父commit对象之后，我们才可以计算提交的的哈希
 203 值并将其存储在数据库，对象数据库不受诸如停电之类的意外中断影响。
 204
 205 我们打败了即使是最狡猾的对手。假设有人试图悄悄修改一个项目里一个远古版本文件的
 206 内容，为使对象据库看起来健康，他们也必须修改相应blob对象的哈希值，既然它现在
 207 是一个不同的字节串。这意味着他们将不得不引用这个文件的tree对象的哈希值，并反
 208 过来改变所有与这个tree相关的commit对象的哈希值，还要加上这些提交所有后裔的哈
 209 希值。这暗示官方head的哈希值与这个坏仓库不同。通过跟踪不匹配哈希值线索，我
 210 们可以查明残缺文件，以及第一个被破坏的提交。
 211
 212 总之，只要20个字节代表最后一次的提交是安全的，我们就将不可能篡改一个Git仓库。
 213
 214 那么Git的著名功能怎样实现的呢？分支？合并？标签？这些都是单纯的细节。当前head保
 215 存在文件+.git /HEAD+ ，其中包含了一个commit对象的哈希值。该哈希值在运行提交
 216 以及其他命令时更新。分支几乎一样：它们是保存在 +.git/refs/heads+ 的文件。标签
 217 也是：它们住在 +.git/refs/tags+ ，但它们由一套不同的命令更新。