《Pro Git（精通 Git）》全书摘要与逐章导读

第 1 章是怎样展开的AI 辅助

开场：一个按历史提出的问题。 这一章根本不是从 Git 开始的。它从一个一般的问题开始：人们怎样追踪变化中的文件，并按逐步升级的顺序把这个问题回答三遍——本地版本控制，然后是集中式，然后是分布式。这个顺序是论证性的，而不仅仅是时间上的。每个系统都被引入，作为对前一个的修补，而集中式模型得到最长的陈述，恰恰因为本章在这里埋下它的核心不满：把全部项目历史放在一台服务器上，把风险集中在一个地方。作者具体地算出了这要付出什么代价——服务器停机一小时，就是一小时里没人能协作或保存有版本的改动，而一块损坏的磁盘，如果没有妥善备份，会带走整个历史。分布式模型随后到来，不是作为新奇事物，而是作为对读者已被引导去感受的一个问题的回答。只有在这番铺垫之后，Git 才以名字出现，带着它 2005 年的起源故事，这个故事与其说是为历史本身，不如说是证明这个设计是在真实的约束下锻造出来的。

展开：从架构到数据模型。 确立了分布式设置里每个客户端都镜像整个仓库之后，本章把这一事实兑现成行为。因为克隆是一份完整的备份，历史和与旧版本的比较，是从本地磁盘读出的；读日志或对照一个月前的文件做差异，不需要一次网络往返，服务器被降为一个共享机制。这就是为什么提交在飞机上也能进行。从这里起，本章提出它最尖锐的主张：使 Git 与众不同的，不是它的命令，而是它怎样思考数据。Subversion 风格的系统保存一组文件，加上随时间对每个文件所做的变更流；Git 在每次提交时记录所有文件的一份快照。作者小心地在同一口气里化解了那个显而易见的反对——没有改变的文件不会被再次存储，而是链接到数据库里已有的相同内容——这样，画面的完整和字节的重复，保持为两个不同的想法。完整性随后以同样的口吻到来：内容先计算校验和，再以该校验和来引用，存在一个四十个字符的 SHA-1 哈希之下，而不是一个文件名之下，而且几乎每个操作都只往数据库里添加东西。这两个事实合起来，就是本章许诺“已提交的工作很难在 Git 不察觉的情况下丢失或损坏”的凭据。三种状态和项目的三个区域，结束了这一块概念内容，给读者一套词汇，带进后面的命令。

转折：从理解到动手。 铰链出现在本章不再解释、开始指示的时候。安装和第一次 git config，标志着从模型转向可用的工具，口气相应地改变——简短、规定性的、机器层面的。身份设置先来，因为没有它们，别的什么也用不了。然后是 init.defaultBranch，本章严格地限定它的范围：它从 Git 2.28 起才有，它命名的是仓库初始化时创建的第一个分支。已经存在的仓库原封不动。这种谨慎是本章方法的特征——它一再把一种能力同其作用范围的确切边缘配成对。

收束：学会盘问，而不是猜测。 最后一个运动是关于自给自足。配置可以整体用 --list 检视，缩小到单个键，或者——最有启发的选项——用 --show-origin 追溯。作者解释为什么这要紧：同一个键可以合法地住在好几个配置文件里，Git 使用最后读到的那个，所以列表里的重复是意料之中的，而不是坏了。比如，询问 rerere.autoUpdate 的来源，会同时打印出决定它的文件路径和值 false，径直说出获胜的文件。这个教训超出了配置之外：当一个值让你意外时，追溯它。本章随后以指引读者去看内置的帮助收尾——git help <动词>、--help、man 手册页，或者用 -h 看简短的选项表——全都可以离线使用。这个结尾优雅地呼应了开头。一章开头是在论证不要依赖远程服务器，结束时表明连文档也已经在你的磁盘上了。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 1 章的核心概念

版本控制

一个随时间记录文件改动、使以前的版本可以被取回的系统。

适用处： 这里用源代码来说明，但几乎适用于任何文件类型。

分布式版本控制

每个客户端都镜像整个仓库，包括它的完整历史，所以每次克隆都是一份备份。

适用处： 消除了单点故障，但分享工作仍然依赖服务器。

快照而非差异

每个提交保存所有文件的一幅画面，对没有改动的文件只链接而不重复存储。

适用处： 与 CVS、Subversion 和 Perforce 这类基于差分的系统形成对照。

三种状态

一个文件是已修改、已暂存或已提交，分别对应工作树、暂存区和 Git 目录。

适用处： 暂存这一步可以跳过，如“Git 基础”所解释。

git config 的层级

系统、全局和本地的配置文件，每一层都覆盖前一层。

适用处： 本地是默认层级，要求处在一个仓库之内。

init.defaultBranch

一个全局设置，命名 git init 创建的第一个分支，取代默认的 master。

适用处： 只有 Git 2.28 以后才有，并且只影响新创建的仓库。

第 2 章是怎样展开的AI 辅助

开场：确立一个起点。 这一章把整个“使用 Git”的问题，收窄成路上的一个岔口：要么把一个已有的目录变成仓库，要么复制一个已经存在的。git init 产生一个 .git 子目录，里面放着仓库的内部骨架——要紧的是，此时还没有任何东西被跟踪——而克隆是从服务器拉下几乎整个历史，而不是只拉某个版本的文件快照。这是一个有意极简的基础，此后的一切都建在它上面：一旦你有了仓库，剩下的唯一问题，就是内容怎样进去。

展开：生命周期，以及对 add 含义的精确。 从这个基础出发，本章转向文件的生命周期——已跟踪对未跟踪，已暂存对未暂存——以 git status 作为一路读出你身处何位的工具。这里关键的论证是：git add 应当被读成“把这个内容精确地记录下来，供下一次提交”，而不是“把这个文件添加到项目”。演示就是证明：作者暂存 CONTRIBUTING.md，再次编辑它，status 随后把同一个文件同时列在“已暂存”和“未暂存”两个标题之下。暂存区捕获的是一个时刻的内容，而不是对文件的实时链接，所以需要第二次 add，来刷新提交实际将含有的东西。对精确的同样坚持，也支配着对 diff 的处理：status 告诉你“哪些”文件变了，diff 打印确切变了的行，而光秃秃的 git diff 有意回答的是更窄的问题：“尚未暂存”的编辑——要看排了队的是什么，需要 --staged（或 --cached）。没有这个说明，读者会错误地以为 diff 报告的是自上次提交以来的一切。.gitignore 和 commit 完成了这一段，只有在仔细的版本确立之后，作者才承认那个捷径：commit -a 完全跳过暂存，这很方便，但因为它把每一处已跟踪的修改都扫了进去，它可能悄悄带上你本不想记录的改动。这个让步被框成用控制换速度，而不是一种改进。

转折：从造历史到修复历史。 本章随后从记录工作，转向回头触及它——移除和移动文件，用 git log 的格式和限定选项读历史，以及用 --amend、git reset HEAD、git checkout -- 和较新的 git restore 撤销。有两处对直觉的纠正，承担了这一节。第一，git mv 并不意味着 Git 存了重命名的信息；Git 一点也不存，而是事后从内容的相似性推断发生了重命名——mv 纯粹是“移动加移除加添加”的方便。第二，--amend 不是一张通用的安全网：它用当前暂存区造出一个“全新的”提交，并抛弃旧的，所以只有当那个提交还是本地的时候才合适，因为一旦共享出去，替换品就不再与协作者所持有的相符。在这两者之下，是作者明确指出的那种不对称：已提交的工作几乎总能挽救，因为一个提交存了一份完整的副本，但丢弃本地改动是不可逆的。恢复一个文件，只是用上次暂存的或提交的版本覆盖它——而本地的编辑从来没在任何地方被做过快照，所以没有东西可以把它们恢复回来。他对修改过的 CONTRIBUTING.md 运行 git restore，之后只有改了名的 README 仍是已暂存的，那个编辑就这么没了。因此有了警告：只在你想让这些改动被毁掉的时候才用它。可喜的是，git status 自己的提示，被展示成教这套词汇的东西——restore --staged 用来取消暂存，restore 用来丢弃。

向外扩展：远程和标签，以及 Git 拒绝自作主张。 本地工作有了保障，协作就登场了：列出、添加、抓取与拉取、推送、检视、重命名和移除远程。组织性的主张是：Git 不会主动在机器之间或分支之间搬动任何东西。从保罗的远程抓取，只是让他的工作在本地作为一个单独的引用 pb/master 可用，你自己的分支原封不动，这样你可以在自己选择的时候检视或合并；合并是有意的第二步，而 git pull 只在分支设置为跟踪一个远程分支时，才把两者合在一起。打标签——轻量对附注，事后补打，分享，删除，检出——从另一个角度说明了同样的一点：push 不发送标签，除非你要求，所以 git push origin --tags 才是传输服务器上没有的标签的办法。下载不是合并，而在本地拥有某样东西，也不是已经发布了它。

收束：方便，与一次交接。 本章以通过 git config 设置的 Git 别名收尾，包括这个细节：别名可以用前导的 ! 调出外部命令——例子是把 git visual 别名为 gitk。这是个贴切的最后一笔：在一章坚持显式性之后，别名让你压缩冗长，而不放弃任何控制。结尾的评估是，读者现在可以做所有基本的本地 Git 工作，下一步是分支——这就把本章定位为基础，而不是终点。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 2 章的核心概念

已跟踪的与未跟踪的文件

已跟踪的文件，是 Git 从上一次快照或暂存中已经知道的文件；未跟踪的文件，是工作目录里其余的一切。

适用处： 只适用于工作目录里的文件，不适用于 Git 有意隐藏的被忽略的模式。

暂存区

一个存放区，你在那里确切地组装下一次提交将要记录的内容。

适用处： 它在 git add 的那一刻给内容拍快照，所以之后的编辑在你再次 add 之前不会包含进去。

作为完整副本的克隆

git clone 拉下服务器几乎所有的数据，而不只是某个版本的工作副本。

适用处： 服务器端的钩子这类不受版本控制的数据不包括在内。

.gitignore 的模式

一个通配符模式的文件，告诉 Git 哪些文件要跳过、不添加或不作为未跟踪的报告。

适用处： 嵌套的 .gitignore 文件只适用于它们自己目录之下；细节留给 man gitignore。

暂存区的捷径（-a）

提交的一个标志，自动暂存所有已跟踪的已修改文件。

适用处： 只涵盖已跟踪的文件，并可能扫进不想要的改动。

隐式的重命名检测

Git 不存重命名的元数据；它事后从内容推断重命名。

适用处： git mv 只是 mv + rm + add 的方便。

第 3 章是怎样展开的AI 辅助

开场：一个兼作论证的定义。 本章从最小的单位开始——分支是一个存着一个提交校验和的 41 字节文件，是架在一串快照之上的可移动指针。作者的框架动作是定义这个东西，并让定义承载论战：老的工具造一个分支，靠把整个项目复制到第二个目录里，这在大型代码库上要花几秒或几分钟，而 Git 只写一个指针，所以这个操作是瞬时的。本章此后的一切都建在这上面。HEAD 被引入，作为第二个指针，它指明你在哪个分支上，这解释了一件否则令人吃惊的事实：切换分支会重写磁盘上的文件：移动 HEAD，迫使 Git 让工作目录与新分支的最后一份快照相符。因此也有了那道防护——当未提交的编辑会被覆盖时，Git 拒绝切换，你要靠储藏或修补来清出路。

展开：指针模型生成了行为。 有了机制，作者推导出合并，而不是宣布它。如果你要并入的分支恰好在你所站位置的前面，就没有什么要协调的，Git 只是把指针滑过去——hotfix 的合并打印出“Fast-forward”。如果两条线分叉了，你的提交不是另一个顶端的祖先，Git 就必须把两份快照同它们的共同祖先合在一起，并记录一个有两个父提交的提交——iss53 的合并报告的是 recursive 策略。冲突是第二种情形的残余，靠手工解决。同样的廉价论证随后扩大成一种习惯：iss91、iss91v2 和 dumbidea 的实际操作序列，把一次性的主题分支展示为日常的普通做法，包括干脆放弃一条工作线索。本章对这种自由的代价是诚实的——删除一个分支，丢弃的是使提交保持可达的那个指针，所以 Git 以“not fully merged”拒绝这次删除，只有强制的变体才通得过，这恰恰就是 iss91 的例子怎样丢掉两个提交的。

向外转：从一台机器到许多台。 本章随后从本地仓库扩展到共享的仓库，口气从机制转向协调。重命名默认分支是最清楚的例子：master 在 Git 里没有特权地位——仓库有一个，是因为 init 创建了它而没人去改名——所以 master→main 不是一条表面的命令，而是一个更新依赖项目、测试和构建配置、托管方的设置和文档、关闭或重新指定拉取请求、并且只在新名字得到验证之后才删除旧名字的工程。远程跟踪分支是另一个纠正。分支列表从不接触网络；它报告的是 Git 在上一次联络时记录的东西，所以你看到的关于远程的一切，是一幅缓存的画面，而不是它的当前状态。抓取，把 origin/serverfix 作为一个不可移动的标记拉下来，标记服务器所处的位置，而不是你能在上面工作的东西——要做工作，你得以它为基础建一个本地的跟踪分支。推送、拉取和删除远程分支，都出自同一个区分：本地指针与缓存指针之间的区分。

收束：变基，先被赞美，然后被划界。 最后一个运动把变基引入，作为合并的替代，并以本章已确立的重放改动的习语来解释它：取自共同祖先以来的每个提交，把它保存为一个改动，把分支移到目标的顶端，按顺序重新应用。内容同合并相符；不同的是形状——一条直线，之后目标靠移动一次指针前进。然后本章把赞美掉了个头。如果你重写了已经推送、且有人在其上建构的提交，你的协作者下一次拉取，就会把你那些被重写的提交的旧版本拖回来，日志里同样的改动出现两次——恰恰是他们打算丢掉的工作。给出的是部分的补救，而不是根治：patch-id 是只针对一个提交所引入的改动的校验和，所以 git pull --rebase 可以比较 patch-id，丢掉其改动已存在于上游的提交，只重放真正新的——只有当被重写的补丁保持几乎相同时才可靠。

落点。 本章拒绝给出胜者。合并与变基被呈现为对历史的两种态度——对发生了什么的事实性记录，对造出了什么的可读故事——而因为团队和项目各不相同，没有通用的裁决可用。作者提供的是一条边界：用变基整理本地的工作，但决不要对任何已经离开你机器的东西变基。这条规则让你既保持刚才演示过的整洁，又避免刚才演示过的协作破坏，并以它开头时的同样逻辑结束本章——分支是廉价的、可塑的，一直到它们被共享的那一刻为止。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 3 章的核心概念

分支模型

Git 的分支方式：移动小小的指针，而不是复制文件，所以分支和合并是廉价而频繁的。 一个团队怎样安排分支：稳定的长期运行的线，加上逐级“毕业”的短命主题分支。

适用处： 描述本地分支指针和合并机制，不涉及远程或变基工作流。 多个长期运行的分支是可选的，在大项目上最有用。

HEAD 指针

一个特殊的指针，指明你当前所在的本地分支。

适用处： 不同于 Subversion 或 CVS 里的 HEAD；这里它指向一个本地分支。

快进合并

当被合并的提交正好在前面时，Git 只是把分支指针往前滑，不产生合并提交。

适用处： 只在没有分叉的工作时适用；否则会创建一个三方合并提交。

三方合并提交

对分叉分支的一次合并，使用两个顶端和它们的共同祖先，产生一个有多个父提交的提交。

适用处： 当双方都改了文件的同一部分时，不能自动完成。

Git 内部原理

Git 把内容存储为快照：blob 存文件内容，一棵 tree 列出它们，一个 commit 指向那棵树及其父提交。

适用处： 本章只用了足够解释分支指针的那点对象模型。

远程跟踪分支

一个你不能移动的本地指针，记录一个远程分支在你上一次网络联络时所处的位置。

适用处： 只靠网络操作更新；不是可编辑的本地分支。

第 4 章是怎样展开的AI 辅助

开场：一个逼出共享会合点的问题。 本章不是从服务器软件开始的；它是从一个论证开始的，论证为什么根本需要一台服务器。作者推论，协作不应当由开发者直接往彼此的副本里推送构成。他靠否定的方式确立这一点，指出什么会出问题：队友的个人机器大部分时间是离线的，所以依赖它的人，每当那台笔记本合上就失去访问；而往一个有人正在使用的仓库里推送，会把进行中的工作搅乱。从这两个失败，引出本章的组织性对象——一个可靠的中间仓库，通常是一个“裸”仓库，放在服务器上。此后的一切，都是对“数据怎样往返这个对象”这一问题的回答。

展开：四种协议，按要紧的维度比较。 目的地定下之后，本章转向传输，列出本地协议、HTTP（分哑 HTTP 和智能 HTTP 两种）、SSH 和原生的 Git 协议。这个比较不是中立的编目；它是沿着方便和安全这两条轴的排序。智能 HTTP 挣得了“使用最广泛的选项”这一说法，理由是一个单一的 URL 同时涵盖匿名读取和认证推送——在 GitHub 这样的服务上，你浏览项目的地址，就是你克隆和推送用的地址——带着一个提醒：HTTPS 配置起来可能有些麻烦。朴素的 Git 协议随后直接放在这番赞美的对面，成为本章论证最尖锐的时刻：它是最快的选项，恰恰因为它跳过了所有密码学和所有认证，而作者用一个实际的攻击演示其代价。一个控制着通往主机路径上路由器的对手，可以改写你所接收的东西，把恶意代码塞进克隆，而这些代码在你编译或运行项目的那一刻就运行起来。通过 https:// 抓取，除非攻击者能伪造证书，就去掉了这种暴露。换句话说，速度是用本可以防止这次攻击的那些保护换来的。

转折：从比较到一台最小可用的服务器，再到逐步锁死。 这里本章把口气从概览转到演示，而它的第一个演示是故意落空的高潮。作者用 scp 把一个裸仓库复制到 /srv/git，并指出，字面上需要的就是这些：任何能 SSH 进来、对那个目录有写权限的用户，都可以立刻克隆和推送。然后他把它扩展到一个小团队，办法是收集约翰、乔西和杰西卡的公钥，把它们追加到一个共享的 git 账户的 ~/.ssh/authorized_keys，初始化一个裸仓库，然后推送——一套完整的多开发者设置，只用密钥和裸仓库就拼起来了。但本章真正的运动，是随后的纠正，而此时很容易把设置读成已经完成。那些用户现在拥有对服务器端目录的完整 shell 访问权，没有什么能阻止他们中的某一个改动或删除 Git 的内部文件，破坏仓库。所以访问被分两层收窄：把 git-shell 设为登录 shell，使推送和抓取仍然能工作，而交互式登录以 fatal: Interactive git shell is not enabled 告终；又因为光这样仍然让 SSH 端口转发可以用来到达别的主机，就把 no-port-forwarding 和配套选项放在每个密钥前面。Git 命令得以幸存；隧道和 shell 则不能。

拓宽：另外三种服务模式，各有各的权衡。 本章随后回到协议列表，把剩下的选项当作部署搭起来。Git 守护进程把认证完全放弃，换取原始的速度和零密钥管理，这使它适合放在防火墙之后，服务许多只读的消费者——否则每个都需要一个 SSH 密钥的构建和 CI 服务器——而在防火墙之外，只适合你乐于使其公开于世的项目；仓库必须一个一个地选择性开放。智能 HTTP 被表明就是 Git 已经自带的 git-http-backend CGI 脚本，而本章小心地说明安全实际住在哪里：这个脚本自己不做任何认证，所以网络服务器强制执行什么，“就成了”Git 的访问策略。一个只对 git-receive-pack 要求有效用户、让抓取保持开放的 Apache 配置块，就是一个协议、一个 URL 怎样同时提供匿名读取和认证写入的办法——而作者建议，即使在这最简单的例子之上，也要叠加 SSL。从这里，本章沿着栈往上走到界面，从轻量的 GitWeb 查看器，到完整的 GitLab 安装，再到第三方托管。

收束：一个政策问题，而不是技术问题。 从两个方向把服务器搭起来之后，本章以权衡自托管与托管服务收尾——一边是控制和自己防火墙后面的隔离，一边是低成本的设置和维护——并拒绝裁决，把这个决定放在机构的政策里。这个结尾同本章一贯的方法一致：每个选项都带着它的价格被呈现，读者手里拿着的是比较，而不是裁决。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 4 章的核心概念

裸仓库

一个只含有 .git 数据、没有检出的工作目录的 Git 仓库，纯粹用作协作点。 一个服务器端的、没有工作目录的仓库，用 git init --bare 创建，只用来接收推送。

适用处： 适合服务器；你不能在里面直接编辑文件。 你不能在里面编辑文件；必须有人登录进去，为每个项目建一个。

Git 传输协议

Git 在仓库之间搬数据的四种方式：本地、HTTP、SSH 和 Git，各有不同的安全与设置上的权衡。 一个通过 git:// 协议、在 9418 端口上完全不带认证地暴露仓库的服务。 通过 git-http-backend CGI 在 HTTP 上提供 Git，让网络服务器提供任何认证。

适用处： 选择取决于认证需求、匿名性、速度和防火墙的约束。 只用于你接受其在网络内公开的数据；每个仓库都必须用 git-daemon-export-ok 选择加入。 这个 CGI 自己不实现任何认证；对非常老的客户端，它退回到哑 HTTP 的行为。

SSH 公钥认证

用户生成一对密钥，把他们的 .pub 密钥交给服务器，这样服务器无需密码就能认出他们。

适用处： 不改变提交的作者数据；要求在服务器上有 shell 访问权。

git-shell

Git 自带的一个受限的登录 shell，允许 Git 传输命令，但阻止交互式的 shell 访问。

适用处： 它本身并不阻止 SSH 端口转发；那需要 authorized_keys 的选项。

GitLab 的命名空间

对每个用户或每个小组的项目的分组，同时构成项目 URL 的路径。

适用处： 每个项目恰好属于一个命名空间，而销毁一个用户，会移除他命名空间里的一切。

合并请求

GitLab 里把一个分支或复刻合并进另一个的提议，带着逐行的讨论。

适用处： 没有推送权限的贡献者必须先复刻；决定什么落地的，仍是所有者。

第 5 章是怎样展开的AI 辅助

本章开头点明了一个结构性事实，其余的一切都由它而来：因为每个克隆都是完整的仓库，每个开发者可以同时既是节点，又是枢纽。作者拿它去对比集中式工具——那里开发者只是围着唯一权威枢纽转的节点——并借这个对比为后文立据：接下来要做的是一次对各种可行安排的巡礼，而不是强推某一种模型。三种安排按规模递增排开：集中式工作流，人人推送到同一个共享仓库；集成管理员工作流，贡献者发布各自的公开副本，由维护者从中拉取；以及适用于超大项目的独裁者与副手安排。这次巡礼的要点是：这些都是选项，项目甚至可以混着用。本章的组织思路已经藏在这里了——贡献和集成是两件分开的事，各有各的节奏。集成管理员循环把它说得具体：维护者推送到规范仓库，贡献者克隆它，推送到自己的公开副本，再请求拉取；维护者把那个副本加为远程，测试、合并、发布。贡献者不必等到被接受，就能继续干活。

开发：灵活变成约束

接着，本章从各种安排转向贡献者的座位，在这个转换里，开头的灵活性变成了一组约束。贡献没有唯一正确的方式；怎么做才对，取决于有多少活跃的贡献者、项目选了哪种工作流，以及你能不能推送。第一个变量背后的道理值得留意：在一个有数千名开发者、每天数百个提交的项目里，你提交的工作可能在等待期间，被陆续落地的合并变得过时或被搞坏——所以提交习惯必须适应项目的规模。提交权限同样坚决地决定路线，比如一个只被允许推送主题分支、不能推 master 的开发者。在演练之前，先插入提交准则：清理空白，把改动按逻辑拆开，一行简短的祈使语气摘要，后面接上说明。然后是最简单的情形——私有的小团队或受管理的团队——被当作一个“抓取—合并—推送”的循环来演练。有启发的时刻是第二次推送被拒。推送只有在能把远程指针往前挪时才会成功；一旦别人的提交已经躺在服务器上、而你本地没有，你的历史就不再是一条笔直的延续，推送会因非快进而被拒绝。把他们的工作抓取下来并合并之后，远程的顶端就能从你的顶端到达，推送随之通过。

转折：走出私有团队，进入公开项目

本章的铰链，是从共用一个仓库的团队，转向你完全没有写权限的项目。这里的建议是：把你的工作作为主题分支推送到你自己的复刻上，而不是合并进你自己的 master，给出的理由是务实的，而不是风格上的：如果工作被拒绝，或只被部分拣选，什么都不用倒回——你直接放弃那个分支就行。演练中，贡献者把复刻加为远程并推送功能分支；当维护者要求变基时，分支在 origin/master 之上重建并强制推送，这样做安全，恰恰因为它是一个无人在其上继续构建的孤立主题分支。第二种公开风格是通过邮件贡献，它带出本章最尖锐的工具论证：用 format-patch 构造邮寄的贡献，而不是普通的 diff。format-patch 为每个提交输出一封 mbox 格式的邮件，带编号，带 From、Date 和 Subject 头，这样接收方就可以用 git am 套用整个系列，并保留原来的作者身份和提交信息。作者自己套用补丁后的结果展示了回报——Author 一行仍是贡献者，Commit 一行记录的是套用补丁的人，这些信息是光秃秃的 diff 根本带不了的。

桌子另一边的开发：维护者

本章的后半段换的是座位，而不是话题，这种对称是有意的：贡献者刚才做的一切，现在都作为别人的收件箱到来。补丁通过 git apply 或 git am 落进专门的主题分支，失败的情形得到了认真的对待。如果一份邮寄的补丁发生冲突，三方选项并不是万能的救星——它的做法是重建补丁所依据的基础树，所以只有当这份补丁所基于的那个提交确实存在于你的仓库里时才管用。没有它，就没有什么可重建的，冲突只能另想办法解决；apply 的检查模式事先告诉你处境如何，并以非零状态退出，好让脚本据此分支。直接从贡献者的远程拉取，被作为更轻量的替代方案提出，接着出现的是评审问题。一旦主题分支和 master 各自都向前走了，拿它们的两个顶端去比较，就会把对方的改动混进画面——master 加的一行，读起来像是你的分支删了它。三点语法修正了这一点：它是对两段历史分叉处的那个提交做差异，只分离出主题分支自己贡献的东西。

收尾：集成例程，然后发布

本章的收尾，先把集成问题放大到规模上，然后从中走出来。维护者需要的例程，随着利害的大小而增长：作者从最简单的情形开始——把主题工作直接合并进 master——指出对较大的项目这会变得有风险，升级到带一个试用分支的两阶段安排，然后在 Git 项目本身里展示极端的情形：它维护着 master、next、seen 和 maint，并随着主题变得稳定把它们往上提升。他明确指出，这个四分支例程是 Git 专用的，不是给别人套的模板，并提到变基和拣选作为合并的替代方案。rerere 让更重的例程变得负担得起：当同样的长期主题被反复合并，同样的冲突会一再出现，所以 Git 记下你是怎么解决的，并在以后的冲突匹配时重放那个解决——这恰恰把反复的试合并变成了一个可持续的习惯。最后一个乐章离开集成，转向发布：用签名标签为一个版本背书，用 git describe 起人读得懂的构建名，用 git archive 产出压缩包，用 shortlog 生成变更日志。于是本章结束在一个维护周期结束的地方——不是代码被接受，而是一次发布，被交还给本章开头那个同样分布式的网络。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 5 章的核心概念

分布式版本控制

每个克隆都是完整的仓库，所以代码可以在许多对等方之间流动，而不只经过一台服务器。

适用处： 灵活是社会性的，不是自动的：团队仍然得就一种工作流、谁能往哪里推送达成一致。

集中式工作流

一个所有人都往里推送的枢纽仓库；后推送的人必须先合并。

适用处： 小团队、大团队都行，但要求人人有推送权限，并在客户端做合并。

集成管理员工作流

每个开发者拥有一个公开的克隆；维护者拉取、测试、合并，并推送到规范仓库。

适用处： 需要一个公认的规范仓库，和一个愿意评审的维护者；贡献者同时继续干活。

独裁者与副手工作流

副手整合各个子系统，仁慈的独裁者把它们合并起来，并推送一个所有人都变基到其上的参照分支。

适用处： 只在巨大或层级森严的项目里才划算，比如 Linux 内核。

提交准则

让补丁能被评审的习惯：没有空白错误，每个提交一个逻辑上的改动集，约 50 个字符的祈使语气摘要，外加详细的正文。

适用处： 是约定，不是强制；书里的示例为了简洁，自己就没遵守。

快进合并

当你的分支严格落后时，Git 只是把指针往前挪，不产生合并提交。

适用处： 当远程有你所没有的提交时，推送恰恰会因非快进而被拒绝。

第 6 章是怎样展开的AI 辅助

本章开头，先把 GitHub 摆在它的位置上：最大的 Git 托管方，也是大多数人头一次以社交的方式、而不是作为本地工具遇见 Git 的地方。本章的切入点刻意平淡：设置账号、验证邮箱、关联 SSH 密钥、添加头像、登记多个邮箱地址、开启双重认证。顺序很重要——它确立了 GitHub 的协作模型建立在身份之上。一旦你带着验证过的密钥和地址存在于这项服务上，本章就可以进入让这个网站对陌生人也管用的机制：复刻加拉取请求。复刻把整个项目复制到你自己的命名空间，你完全掌控那里，所以你在那里提交和推送，而不是推到原仓库。贡献则以拉取请求的形式送回去，由维护者决定合并与否。这种所有权的划分是本章的核心洞见：维护者在接受外部工作之前，从不必发放推送权限，因为对原仓库的写权限始终锁着，只有一份请求越过边界。

开发阶段具体地走一遍流程——复刻、创建主题分支、推送、开拉取请求——然后着重讲评审者回应时会发生什么。示例刻意很小：托尼把闪烁延迟从 1000 毫秒改成 3000 毫秒的一行改动。反馈到来时，办法是往同一个主题分支上推送额外的提交，而不是把提议重新作为第二个拉取请求发出来。理由是，持久的记录是评审对话加最终的合并提交，GitHub 的合并按钮有意写下一个指回拉取请求的合并提交，让讨论始终可以到达。改写提交什么也买不到，反而会破坏讨论串所指向的东西。同样的逻辑管着过时的请求：把原仓库加为 upstream 远程，抓取，把 upstream/master 合并进你的主题分支，解决冲突，推送——拉取请求就会自己更新并重新测试。如果你真想变基，所说的条件是把它推送到一个新分支，并另开一个引用旧请求的新拉取请求。用 #num 交叉引用议题，补全了社交层，接着是 GitHub 风格的 Markdown：任务列表、围栏代码、引用、表情符号、拖放图片。

让复刻保持最新，被当作一件杂务，而不是一项功能。本章直截了当地说，GitHub 永远不会替你更新你的副本，展示了每次都写出抓取 URL 有多烦琐，然后配置一个带推送默认值的 upstream 远程，让这套例行动作缩成检出、拉取、推送。随之而来的是一句警告：在这个方便的设置里，Git 不会拦着你往一个内容其实属于上游的 master 分支上提交。这是本章对一种自然的误读最尖锐的纠正——远程只是省了你重打一个 URL；同步仍是手动的，因为托管方从不自己刷新一个复刻。

转折出现在视角从贡献者翻到维护者的时候。现在本章创建仓库、添加协作者，并从桌子的另一边处理收到的拉取请求。这里技术上的回报是拉取请求引用：对示例仓库运行 ls-remote，会暴露出服务器端的引用，比如 refs/pull/1/head 和 refs/pull/1/merge，与普通分支并排而坐。它们默认被跳过，恰恰因为它们住在 refs/heads/ 之外，但给它们加一个引用规格，就让每个拉取请求都作为一个本地只读的跟踪引用出现——不用给每个贡献者添加远程，这去掉了本地评审的大部分烦琐。拉取请求上的拉取请求，以及提及与通知系统，补全了维护者的工具箱。

收尾向外扩展到 GitHub 的扩展点，从约定走向可编程的表面。先是通知邮件的头，然后是编码了项目期望的特殊文件 README 和 CONTRIBUTING；接着是项目管理——选择默认分支、转让所有权——以及带团队和审计日志、用于规模化工作的组织。最后是钩子、服务和 API。本章把区别讲得很清楚：webhook 让 GitHub 在事情发生的一瞬间，把事件载荷 POST 给你托管的服务，这样你不用轮询就能知道有推送；而 API 朝着另一个方向走，让你的代码请求更多细节或写回——比如在议题上发一条评论。一个提供触发，一个提供后续。压轴的示例把两者连了起来：一个 webhook 扫描收到的提交里有没有 Signed-off-by 一行，并通过状态 API 发布成功或失败的状态，它在提交列表和拉取请求上显示为绿色对勾和红色叉。这把你在意的任何策略，变成合并时一个看得见的通行/禁止信号，作者指出它对测试结果尤其有用，免得有坏东西被意外合并。他还说出了局限，纠正了一个诱人的假设：拉取请求的视图只反映最后一个提交的状态，所以绿色对勾并不证明分支里每个提交都没问题——状态是按提交附着的，上下文标签只是区分谁报告了什么。于是本章结束在它开始的地方，重机制而不重魔法：GitHub 提供钩子和 API，而你得到的保证，是你自己建起来的那些。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 6 章的核心概念

GitHub 复刻

把别人的项目复制到你自己的命名空间里，这样你无需成为协作者就能往里推送。

适用处： 当你已经有写权限时就不需要；拉取请求也可以在同一个仓库的两个分支之间开。

拉取请求

一个基于网页、请求合并你主题分支的请求，带着一份差异，外加一个支持逐行代码评审的讨论串。

适用处： 额外推送提交会悄悄地更新它——追加提交不会发送通知。

GitHub 流程

一个八步循环：复刻、主题分支、提交、推送、开拉取请求、讨论、所有者合并或关闭、把 master 同步回来。

适用处： 它就是集成管理员工作流，只是用网页工具代替了邮件列表里的邮件。

交叉引用

在任何评论里写 #num、username#num 或 username/repo#num，链接到另一个议题或拉取请求。

适用处： 同一个项目里，议题和拉取请求共用编号，所以 #3 不能同时是两者。

SSH 公钥认证

把你的公钥粘贴进 GitHub 设置，让 SSH 远程能用；给每个密钥命名，以后可以吊销正确的那个。

适用处： 克隆公开项目，或用用户名和密码做 https:// 推送时，不需要。

双重认证

登录时，除了密码，还要求第二个验证码，来自手机应用或短信。

适用处： 它防的是密码被盗，不防账号遭遇的其他泄露途径。

第 7 章是怎样展开的AI 辅助

本章从一个高级工具包必须先回答的最基本的问题开始——你怎么指向你想要的那个提交？它从缩写的 SHA-1 开始，并用开篇的论证为它们辩护：实践中八到十个字符就够了，并以 Linux 内核作为压力测试的例子（到 2019 年 2 月，有超过 875000 个提交和近七百万个对象，连前十二个字符都没有出现过两个哈希相撞），外加一个思想实验，显示即便荒唐的推送量，也要花上多年，才会让一次意外碰撞的概率达到抛硬币的程度。警告说得明明白白：这个界限针对的是意外，而不是攻击。从这里起，词汇按自然的顺序拓宽——分支名、reflog 简称，然后是用 ^ 和 ~ 表示的相对祖先关系，再是通过双点、^/--not 和三点表示的整个范围。整个开篇的要点是杠杆：一旦你能精确地命名任何提交或一组提交，本章后面的每个工具就有了可以操作的对象。

开发：塑形、停放、签名、搜索

在确立了如何指称提交之后，本章转向如何做出好的提交。交互式暂存（git add -i）和补丁模式，被呈现为提交卫生的手艺：暂存一个块，让文件的其余部分不动，得到的是一个聚焦的改动集，而不是混杂的，这样每个提交都是评审者能跟得上的、单一而自足的改动。同样务实的精神延续到 git stash——save、list、apply、drop、pop、--keep-index、-u、--patch、stash branch——它被介绍为放下做了一半的工作、不必提交就能切换任务的办法，但马上加了限定：重新套用会恢复这些编辑，却把已暂存/未暂存的区别压平，除非你传 --index，而且普通的 apply 会把条目留在栈上。git clean（以 -n 和 -i 作为安全护栏）处理储藏不该碰的东西。然后是两段较短的内容：对标签、提交和合并做 GPG 签名，用于出处要紧的时候；以及搜索，通过跨工作树的 git grep，和跨历史的 git log -S/-G/-L——pickaxe，回答的是“这个字符串是什么时候出现或消失的？”，而不只是“它现在在哪儿？”

转折：重写历史与三棵树

git log -L 追踪一个函数或一段行范围穿越时间，是这里的铰链：本章从阅读历史滑向重写历史。修补（amend）、交互式变基（reword、edit、重排、squash、拆分、drop）和 filter-branch，按破坏性递增的顺序到来，随之而来的是本章核心的伦理界线——重写是一种特权，它在你推送的那一刻结束，因为变基已经到过共享服务器的提交，会把同一个改动的第二份、相互竞争的副本交到协作者手里。重写之所以具有破坏性的机制性原因，也得到了专门的解释：每个提交都存着它父提交的哈希，所以一个提交的身份就是它的整个祖先；编辑或丢掉其中一个，下游的一切都会以新的哈希重建，只有在这次编辑之前被重放的、没动过的提交，才保留了它们旧的身份。

“重置揭密”是本章概念上的中心，它把一个令人畏惧的命令重新框定成一个可预测的命令。Git 持有内容的三份副本——HEAD 所指的提交、索引、工作目录——而重置按固定顺序走过它们：移动 HEAD 所指的分支，让索引与之匹配，让工作目录与之匹配。--soft 在第一步之后停下；--hard 三步全做；指明路径则完全跳过分支的移动。这个顺序化解了常见的恐惧，即以为重置就是那个会毁掉工作的命令。只有 --hard 会碰磁盘上的文件，这是重置唯一可能不可挽回地丢失东西的方式——这就是为什么 reset --soft HEAD~2 加一个新提交，能压缩历史而保留每一处编辑。就连 --hard 的例子，也是通过 reflog 恢复了一个旧文件，不过本章小心地交代了原因：那些内容已经提交过。未提交的内容就真的没了。git checkout 随后被放到重置旁边作为对照——它移动的是 HEAD 本身，而且对工作目录是安全的。

高级合并，然后是调试

接着是高级合并，它建立在一个关于 Git 设计的有意断言上：它有意不聪明，只解决毫不含糊的部分，把其余的交给你。例子是一个分支，有人把每一行的行尾都重写了，并改了一个词——Git 把每一行都读作被修改，并在整个文件上冲突——这引出了随后的忽略空白的策略、通过索引阶段手动重新合并，以及 --conflict 重新检出。然后是舒适的工具：diff3 冲突风格、--ours/--theirs 检出、合并日志、组合差异、-Xours 和 -s ours、子树合并，以及 rerere 来记住你已经做过的解决方案。撤销合并得到一个尖锐的区分：revert -m 添加一个抵消改动的提交，却把合并留在历史里，所以主题分支里的一切仍然可以到达，再试一次合并只会报告“Already up-to-date”——你必须还原那次还原，才能把工作找回来，而 reset --hard 则真正抹掉了合并，代价是重写共享的历史。调试然后按各自回答的问题，把两个工具配成一对：git blame（用 -L 指定行范围，用 -C 追踪复制的代码），用于你知道问题在哪里的时候；而 git bisect，带着它的二分查找和自动化，用于你只知道有东西坏了的时候——演练标出一个坏提交和一个好提交，测试中点，最终落在 b047b02 上。

收尾：子模块、传输与可扩展性

最后一段从单个仓库向外移动。子模块围绕一个事实被引入，这个事实解释了它们的全部摩擦：超级项目只存着子模块的提交 id，而不是它的文件。因此，一次全新的克隆会让那个目录保持空着，直到 init 和 update（或 --recurse-submodules），而拉取外层项目只是抓取新被引用的提交——还需要一个单独的 update 步骤才能把它们检出来。然后本章诚实地走过种种后果：在子模块里工作需要一个检出的分支加上 --merge/--rebase，推送需要 --recurse-submodules，分叉的子模块指针必须手工合并，而重新添加或切换分支有它们自己的陷阱。三个较短的收尾把范围进一步拓宽：git bundle，用来在没有网络时通过“运动鞋网络”搬运历史；git replace，用来把被截断的历史嫁接到它更早的延续上；以及凭据助手系统，带着它的 stdin/stdout 协议。本章结束在一次扩展的行动，而不是总结——在展示了原始的 git-credential-store 和它的纯文本文件之后，它用 Ruby 建了一个小小的只读助手，读取一个共享的凭据文件，并通过 credential.helper 注册自己。这对一章讲工具的内容是个恰当的收尾：用整章的篇幅讲了 Git 提供什么之后，它最后表明，这个工具包在边缘是敞开的。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 7 章的核心概念

简短的 SHA-1

哈希的前几个字符代替完整的 40 个字符，只要它们是唯一的。

适用处： 至少要四个字符，并且没有其他对象共用这个前缀。

RefLog 简称

Git 记录 HEAD 和各分支最近指向过哪里，所以你可以说 HEAD@{5} 或 master@{yesterday}。

适用处： 严格是本地的，而且只覆盖最近几个月；新克隆的仓库 reflog 是空的。

祖先引用

^ 表示一个父提交（用数字选择是哪一个父提交），~ 重复地沿着第一个父提交往上走。

适用处： ^2 只对合并提交有意义，因为只有它们有不止一个父提交。

双点

master..experiment 列出从一个引用能到达、但从另一个引用到达不了的提交。

适用处： 仅限两个引用；省略一边，Git 就假定为 HEAD。

三点

master...experiment 显示从任一引用能到达、但不是从两者都能到达的提交。

适用处： 配上 --left-right，可以看出每个提交来自哪一边。

交互式暂存

git add -i 打开一个用于暂存、取消暂存、比较差异，以及按补丁粒度暂存文件的 shell。

适用处： 补丁模式在它之外也能用，通过 git add -p、git reset --patch、git checkout --patch、git stash save --patch。

第 8 章是怎样展开的AI 辅助

开头：配置作为分层的默认值。 本章从自定义最熟悉的一层——配置文件——开始，并立刻确立它的支配逻辑。Git 依次读三个文件：整台机器的，然后是每个用户的，然后是仓库内部的，后读的各自覆盖之前的。作者把三个命令行开关对应到这三个文件上，并指出，你根本不指定层级时得到的就是 --local，这也是那句安静的包袱：因为仓库自己的文件最后被读，并且是写入的默认目标，一个项目的选择就悄悄地压过机器或用户设的任何东西。从这个框架出发，本章走过实用的清单——编辑器、提交模板、分页器、签名密钥、全局排除、自动纠正，然后是颜色，然后是外部 diff 和合并工具，然后是空白和换行符的处理。这一段在服务器一侧结束，语气也从规定转向对取舍的推理：完整的对象一致性检查默认是关的，因为对大型推送验证校验和很贵，所以安全是用速度换来的；而拒绝非快进推送本身是有漏洞的，因为用户可以删掉一个分支再把它全新地推回去，这恰是为什么需要另一个拒绝删除的选项，来堵上这个漏洞。

发展：从整仓库设置到按路径的属性。 从配置里转出来是有动机的，而不只是宣布。有些行为无法为整个仓库决定，作者的测试案例是一个机器生成的项目文件：把 pbxproj 模式声明为二进制，既阻止 Git 产出没人看得懂的 diff，也阻止它改写换行符，即使该文件技术上是文本。没有哪个全仓库范围的开关能说“只针对这一种文件”——这个缺口，就是按路径作用域的属性所填补的，使它们成为刚讲过的配置层的天然对应。属性随后扩展到远远超出把东西标成二进制。二进制文件可以被纳入真正的审阅：在比较之前把它们转换成文本，而不是比较字节：让 Word 文档经过文本提取器，Git 就会准确报告被加上的那句话；让图像经过元数据读取器，文件大小和像素尺寸的变化就以普通的行 diff 浮现。作者对这里的天花板很小心——文档内部的格式改动永远不会出现，因为转换器从不输出它们。关键字展开得到类似机械的解释：由于 Git 对文件内容做校验和来决定提交是什么，文件在提交存在之前，无法含有它自己的提交信息，所以出路是一对过滤器——clean 在暂存时把占位符还原成它的光秃形态，smudge 在检出时代入真实的值——使存储的内容保持稳定，而工作副本看起来是展开的。用于归档的 export-ignore 和 export-subst，以及按文件的合并驱动，补全了这一节。

转折：从配置到强制执行。 手握两种配置机制，本章从设置转向在恰当时刻运行的程序——钩子，先在客户端一侧概览（提交、电子邮件和杂项），再到服务器（pre-receive、update、post-receive）。这个概览是有意预备性的；它的存在，是为了给收束本章的那个长示例铺垫。

收尾：一台强制执行政策的服务器，然后是客户端的早期预警。 本章的回报是：政策属于服务器，在那里钩子才真能拒绝一次推送——而两个服务器钩子的区别，在于它们能拒绝得多细。其中一个从标准输入收到被推送引用的整张列表，以非零退出码，一次就杀掉整个推送；另一个被交给单个引用名及其新旧修订，每个分支运行一次，所以能只拒绝那一个分支。作者在这个粒度上继续搭建：列出一次推送引入的提交，让钩子检查每条消息是否有要求的模式，读一个访问控制文件，让它拿每个提交碰过的文件，去比对该用户被允许写入的路径。被拒绝的推送会打印政策消息，Git 报告钩子拒绝了这次更新。但本章并不止于不行。只在推送时才被拒绝的工作，得在事后重写——用作者的话说，极其令人沮丧——所以同样的检查也被装到本地：commit-msg 钩子当场中止格式糟糕的消息，而带着预期引用标记的则放行，pre-commit 钩子检查访问控制列表，pre-rebase 钩子守护历史，提交模板则让要求的格式一开始就更容易遵循。

结尾那一节隐含的两点警示。 这两种机制走得都没有看上去那么远。只有属性的规则随代码一起提交；它们点名的辅助程序不会，所以一台缺少过滤脚本的机器上的克隆，就是得不到展开——这就是作者警告，这类过滤器应写成优雅地失败，而不是让检出崩掉的缘故。同样，本地钩子在克隆时不会被复制，必须手动安装，这意味着 commit-msg 和 pre-commit 检查是给个别开发者的早期预警，绝不是全团队的义务。这条规则只有在服务器端的钩子也检查它时，才变得具有约束力——恰是本章最后那个示例所演示的分工。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 8 章的核心概念

git config 的层级

Git 依次读取的三个文件——系统级、用户级、仓库级——越近的文件越优先。

适用处： 只涵盖存在配置文件里的设置；按路径的行为则需要属性。

Git 属性

写在 .gitattributes 里的按路径设置，告诉 Git 怎样对特定文件做 diff、合并或过滤。

适用处： 作用域是仓库里的路径；用 .git/info/attributes 可以让它们不被提交。

core.autocrlf

在提交时把 CRLF 换行符转成 LF、并可在检出时转回去的设置。

适用处： true 适合 Windows，input 适合 Linux/macOS，false 适合纯 Windows 项目。

外部 diff 和合并工具

包装脚本加上 merge.tool/diff.external 设置，把 diff 和冲突引向一个 GUI 程序。

适用处： 许多工具是预设的，无需 cmd 配置；窗口式工具在纯终端会话里会失败。

textconv 过滤器

Git 在 diff 之前运行的、把二进制文件转成可读文本的程序。

适用处： 它只会露出转换器输出的东西；.docx 里格式的改动依然看不见。

clean 与 smudge 过滤器

成对的脚本：clean 在文件被暂存时运行，smudge 在文件被检出时运行。

适用处： .gitattributes 文件随项目一起走，驱动程序却不会，所以过滤器必须优雅地失败。

第 9 章是怎样展开的AI 辅助

本章从一个让步开始，而不是一个论点：不是你做的每个项目都是 Git 项目，也不是每个团队都能被说服迁移。从这个承认出发，本章推出了它的目的。如果你不能把仓库带到 Git 那里，至少可以把 Git 带到仓库那里——把 Git 用作一个通过桥接与外部服务器对话的客户端。开头点出了随后的两半：先是双向桥接，让你在别人的服务器仍然握有权威的情况下继续工作；后面是单向的迁移路径，以历史真正住进 Git 告终。git svn 被介绍为前半部分的旗舰，因为 Subversion 是 Git 用户最可能被困在其中的系统。

如何展开：git svn 的纪律

对 git svn 的处理，是本章最长也最带警告意味的一段，它整个论证都从一个结构性事实往下推：Subversion 只能记录一条线性的历史。所以，Git 所做的任何分支或改写，在桥接的另一边都没有忠实的翻译。实际的后果被写成规则而不是选项——用变基而不是合并，并把 SVN 服务器当作团队唯一的碰头点。作者直言不讳，在 SVN 远程之外再加一个原生的 Git 远程，是典型的错误：同样的工作获得了两个互不兼容的身份，而本来就容易被弄糊涂的 SVN 服务器无法调和它们。准则一节把这一点硬化为强制措施，建议用一个 pre-receive 钩子，拒绝任何缺少 git-svn-id 一行的提交信息。总结性的判断是，git svn 交给你的是一个有意缩减过的 Git：本地分支、暂存区、变基和拣选都真的可用，但严格是作为私人工具，只有一条直线被允许到达服务器。

第一个转向：Mercurial，约束放松的地方

定下这些限制之后，本章转向 git-remote-hg，恰恰是为了展示一个受约束少得多的桥接——对比正是重点。机制按顺序铺开（克隆、refs/hg 映射、notes 映射、忽略），然后是回报：因为 Mercurial 原生理解合并，一次普通的 git merge origin/master 接着 git push，就能直接更新 Mercurial 仓库，演练中一个变更集是在 Mercurial 一侧写的，接下来的几个从 Git 一侧抵达，无需特殊处理。书签对重量级分支，补全了图景。这里只有一个 Git 习惯必须放弃，而它是 Mercurial 根本没有概念的：重写历史。Mercurial 只增不减，所以变基加强制推送，会把重写后的工作作为全新的变更集 8、9 和 10 落地，而被取代的原件原封不动地躺在它们旁边，协作者看到同样的工作两遍。作者把这个教训推广到桥接之外——避免重写已发布的历史，在哪里都是好的做法。

第二个转向：Perforce，从服务器端到客户端

Perforce 被当作坐落在连接两侧的两个不同桥接来处理，本章小心地不让它们混在一起。先是 Git Fusion：一个服务器端的产品，需要管理员的配合、它自己的 INI 配置文件和一张用户映射，把变更集转成提交，再转回来，透明到双方都注意不到对方。然后视角翻转到 git-p4，它完全住在你自己的克隆里，不需要改服务器，并通过 p4 命令行客户端与 Perforce 对话。因为 Perforce 的分支模型与 Git 里的任何东西都不像，git-p4 采用线性化，而不是提交合并提交：同步之后，master 和 p4/master 分叉，git p4 rebase（同步再加一次变基到 p4/master）把它们理顺。提交一个包含合并的分支，三个非合并的提交产生了三个变更集。作者提炼的规则简单得令人愉快——如果你能变基一段历史，你就能贡献它，所以本地分支依然自由——但代价说得明明白白：哪些分支被合并过的记录被丢弃，创建或整合分支仍然需要 Perforce 客户端，而提交会在每个提交信息后追加一行 depot 路径，改变它的内容，从而改变它的 SHA-1，所以你最终得到的提交，并不是你事先分享的那些。

如何收尾：迁移，然后是推广

本章的最后一个乐章把桥接抛在身后，转向单向迁移，它一贯的信息是，一次好的导入值得准备，而不是匆匆来一次 git svn clone。因为 Subversion 的导入既慢又不完美，作者先建一个作者文件，把 SVN 用户名映射到真实姓名和邮箱，并传 --no-metadata，产生带有恰当 Author 字段、没有 git-svn-id 一行的提交——这份元数据，只有你仍打算把提交镜像回 SVN 时才值得保留。接着靠手工收尾：循环遍历 refs/remotes，把远程引用转成真正的 Git 标签和分支，删掉名字里带 @ 的固定修订版引用，以及重复的 trunk 分支，然后用 --all 和 --tags 推送。Mercurial 通过 hg-fast-export 讲得更简短，Perforce 则借助已经讨论过的 Git Fusion 和 git-p4 工具。

收尾的动作是推广到那些有现成导入工具的系统之外。对其他任何东西，作者的建议是把导入写成喂给 git fast-import 的纯文本脚本，他论证说这比用原始的底层命令去组装对象要容易得多。演示是一个简短的 Ruby 脚本，遍历带时间戳的备份目录，对每个快照打印一个 mark、一个日期、一个提交者、一个 deleteall 和内联的文件数据；把它的输出管道接进 fast-import，在单个分支上产生了 4 个提交中的 13 个对象，唯一的平台注意事项是 Windows 需要把 stdout 设为二进制，因为 fast-import 只接受 LF 行尾。于是本章结束在它最赋予人力量的地方：用整章的篇幅讲了别人的服务器所强加的种种妥协之后，它最后表明，任何历史都能被变成 Git 的历史。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 9 章的核心概念

git svn 桥接

一个双向适配器，让你在本地使用 Git，而 Subversion 服务器仍是事实的来源。

适用处： Subversion 只保留一条线性历史，所以要避免重写历史，或推送到并行的 Git 远程。

版本控制系统的桥

一些适配器，让一个开发者即使在团队的服务器跑着另一个系统时也能使用 Git。

适用处： 只涵盖常见的几种；每个桥接都继承外部系统的局限。

远程助手桥接

Git 调用的一个程序，通过正常的远程接口与非 Git 仓库对话。

适用处： 对 clone/fetch/push 管用，但继承种种局限，比如无法从 Git 一侧删除 Mercurial 书签。

书签对重量级分支

Mercurial 的书签行为像 Git 分支；Mercurial 的分支则永远记录在每个变更集里。

适用处： Git 复制不了所记录的分支字段，所以重量级分支通过 branches 命名空间来访问。

Git Fusion

一个 Perforce 产品，在服务器端把 Perforce 服务器与 Git 仓库同步。 一个服务器端的服务，把 Perforce 变更集转成 Git 提交，再转回来，让 Git 和 Perforce 的用户彼此从未察觉。

适用处： 服务器端产品，有它自己的 INI 配置和用户映射；git-p4 是不需要改服务器的客户端替代方案。 需要服务器管理员的配合；拒绝重写已经推送的历史。

本地排除文件

一份存在磁盘上、从不提交的、针对单个仓库的忽略清单。

适用处： 当你不能把 .gitignore 提交进外部仓库时有用。

第 10 章是怎样展开的AI 辅助

开篇：一个揭示，被框定为一次反转。 本章一开始就把读者心里关于 Git 的图景的地板抽掉。迄今学到的一切——add、commit、branch——原来都是“高层命令”，是盖在一种截然不同的东西之上的便利层：一个内容寻址的键值文件系统，上面装了一个版本控制的界面。本章先确立这个区别（底层命令对高层命令），然后通过游览 .git 目录把它落到实处，让抽象有了地址。随后的演示是本章开头的证明：把 test content 管道接进 git hash-object -w --stdin，返回一个四十个字符的哈希，对象出现在磁盘上。然后这个哈希被手工重现——在内容前面加上类型和大小的头以及一个空字节，对整个字符串取 SHA-1——结果完全吻合。这单一的吻合，承载着本章的核心机制：键不过是这些字节的一个函数，所以相同的内容总是落在相同的地址。

展开：一层一层向上构建 Git。 从 blob 出发，本章通过揭示每一层缺少什么，来构造对象模型。blob 装着内容，却没有名字，所以引入树，把模式、类型、文件名和哈希配对——指向 blob 或其他树。树是一份快照，却没有作者、祖先，或存在的理由，所以构造出提交对象，来命名一棵顶层树，外加父提交、身份和信息。然后读者把 hash-object、update-index、write-tree 和 commit-tree 链起来做三遍，得到一份真正的历史，git log 把它显示得就像是正常做出来的一样——这是本章的证据：高层命令自动化的恰恰是这个序列，仅此而已。这份手工搭建的历史，也因为变得痛苦而引出下一步：记住每个版本的哈希不现实，于是引用作为解决办法登场。把一个哈希写进 .git/refs/heads/master，git log master 就立即能用了，这把分支简化为指向某个提交的指针。值得注意的是，本章只演示一次原始的文件写入来说明这个想法，然后就把读者引向 git update-ref 这个受支持的接口——同样的护栏逻辑，让 git symbolic-ref 拒绝把 HEAD 指到 refs/ 之外。

中段的扩展：其余一切都是薄薄的约定。 有了 blob、树、提交和引用，本章的方法就变成了重复：其余每个 Git 功能，都被表明是盖在同一个存储之上的一点小约定。HEAD 是一个符号引用，指名当前的分支。标签是第四种对象类型。远程引用是只读的书签。打包文件是这里唯一真正全新的机制，它纠正了本章一直在铺垫的一种误读：提交存的是完整的快照，而不是差异，所以对一个 22K 文件的一行编辑，会留下两个近乎相同的 blob（22054 和 22044 字节）并排放着。节省空间来自另一个机制——git gc 把 15K 的松散对象重写成一个 7K 的打包文件，完整保留最新的版本，把较旧的那个存成一个九字节的增量，因为最近的版本是你需要得最快的。本章诚实地指出，这些数字来自一个很小的演示仓库。

转折：从存储到传输。 解释完存储之后，本章转向外部，看两个仓库怎样交换它。引用规格提供远程和本地引用之间的映射；哑协议和智能协议提供移动。握手——send-pack/receive-pack 和 fetch-pack/upload-pack——在 SSH 和 HTTP 两种方式下都被走了一遍，演练的要点是，推送不是盲目的文件复制，而是一场协商：带长度前缀的块，每块以一个四字符的十六进制长度开头，然后是旧哈希、新哈希、引用名，全零的旧哈希表示一个不存在的分支。在 HTTP 上，同样的对话只是拆成了对 info/refs 的一次 GET，和一次携带 send-pack 输出与打包文件的 POST。

收尾：维护、恢复，以及删除的局限。 最后的乐章是实用的，它的回报来自前面建起的模型。自动 gc 和 packed-refs 管内务；reflog 和 fsck 管恢复那些看起来已经丢失的东西。然后是最有启发的案例：提交删除一个 5MB 压缩包的操作，什么也没回收——size-pack 仍然报告 4868KB——因为这个 blob 仍可通过旧的提交到达。只有用 filter-branch 重写每一棵过去的树，清理剩余的引用，再运行 gc，才把打包后的仓库降到 8K，即便如此，对象仍可能松散地逗留，直到 git prune --expire，并带着一个警告：重写历史会迫使协作者变基。一份环境变量的清单（路径规格通配、提交身份、HTTP 网络、差异与合并行为、追踪）结束了本章，它结束在开始的地方：懂得了底层命令，就能把 Git 用成它实际的样子——一个内容寻址的文件系统。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 3 个机制。

常见误读

第 10 章的核心概念

Git 内部原理

Git 命令底下实际的存储机制：.git 目录、对象数据库和引用。 底层命令是给脚本用的低层构件；高层命令是你每天键入的友好命令。 日常高层命令底下的低层底层命令。

适用处： 对理解和写脚本有用，但使用日常的高层命令并不需要。 底层命令多半不打算在命令行上手工运行。 对自定义工具有用，普通的日常工作流不需要。

内容寻址文件系统

一个键值存储，键是对内容本身算出来的哈希，所以相同的内容总是得到相同的键。

适用处： 它只存内容——文件名住在树对象里，不在 blob 里。

blob 对象

一块存起来的文件内容，由头加内容的 SHA-1 命名，不附带文件名。

适用处： 自身不带名字、模式或历史。

树对象

一份目录清单：各条目把模式、类型、文件名，和一个 blob 或子树的 SHA-1 配成对。

适用处： 由索引状态构建，通常通过 git write-tree。

提交对象

一条记录，指名一棵顶层树、它的父提交、作者/提交者数据和一条信息。

适用处： 提交指向的是整棵快照树，而不是差异。

对象存储

每个对象都存为：类型和大小的头，加一个空字节，加内容，先 SHA-1 哈希，再 zlib 压缩，存到按 2/38 拆分的路径上。

适用处： 所有类型都是同样的方案；只有提交和树的内容有严格的格式。

附录 A是怎样展开的AI 辅助

开篇：终端并非故事全部的前提。 附录一开始，先承认读者刚刚学完的东西——命令行 Git——然后有意地把它相对化。它论证说，Git 通常是一个更大生态系统中的一个组件，而终端并不总是进入它的最佳入口。这把接下来的一切框定为对环境的巡礼，而不是对命令的巡礼。第一站是图形界面，在这里，本章确立了一条它将反复依赖的评价原则：不同的客户端是为不同的工作流而造的，所以没有哪个单纯“比”另一个“更好”；它们只是更适合或不那么适合某个目的。紧接着附上了第二条、起平衡作用的断言——图形界面能做的任何事，都没有超出命令行，命令行保留着最大的威力和控制。这一对说法（图形界面是正当的，却从不是超集），就是本章安静的论点。

展开：图形界面，从面向任务到面向工作流。 论证然后通过举例推进。先是 Git 自带的工具 gitk 和 git-gui，被呈现为面向任务的：gitk 是 git log 和 git grep 之上的图形外壳，用来查找和可视化历史，git-gui 是一个精心制作提交的工作台，左边是索引，右上是块级和行级的差异视图，右下是信息/提交/修补控件。文字总结说，每个都只做一件事，省掉那件事不需要的东西。然后，macOS 和 Windows 的 GitHub 客户端，作为对照的类别，是面向工作流的：围绕“GitHub 流程”——提交到一个分支并经常同步——而搭建的一套精选功能。本章对这个取舍很具体——单个“Sync”按钮把拉取、变基、回退合并和推送压成一个多步动作，恰恰因为去掉了选择而节省时间。它的总结相应地带条件：对它所设计的工作流极好，但如果你的工作流不同，或者你想控制网络操作何时发生，就用别的东西。想要替代品的读者，被指向精选的和全面的外部清单。

第一个转向：从独立客户端到编辑器。 本章随后转换语域，从就是 Git 前端的应用，转向内嵌 Git 的应用。Visual Studio（自 2019 16.8 起）、VS Code（需要 Git 2.0.0+）、JetBrains IDE 家族，以及 Sublime Text（自 3.2 起），各自得到一份压缩的功能清单——克隆、分支、暂存、提交、推送/拉取/同步、解决冲突、查看差异——外加扩展和文档的指引。这里的处理刻意很薄、像目录，有一个细节揭示了背后的逻辑：JetBrains 的集成依赖于已安装的命令行 Git 客户端。它们不是 Git 的替代品，而是盖在它之上的表面。

第二个转向：配置终端本身。 离开命令行走了一圈之后，本章带着不同的提议转回头来——不是放弃 shell，而是改进它。Bash 通过 git-completion.bash 获得补全，通过 git-prompt.sh 获得提示符，PS1 的构造被一块一块地解释。Zsh 被呈现为更强大：补全带着描述，而且可以导航，vcs_info 向左或右提示符提供分支信息，git-prompt.sh 和 oh-my-zsh 框架作为替代方案提供。PowerShell 结束了这个序列，cmd.exe 被斥为无法使用，推荐 posh-git，包括先决条件 ExecutionPolicy 的讨论、仅为一个用户或为所有用户的范围选择、从库中安装和从源码安装的路径，以及关于 Windows PowerShell 的发布者证书不同的排错说明。

收尾。 结尾简短，而且比此前的内容稍微宽泛，声称读者现在可以在日常工具内部挥舞 Git，也可以从自己的程序中触及仓库——是对附录更大弧线所涵盖的编程式集成的点头。从结构上看，本章描出一条向外再折返的弧线：从命令行出发，穿过图形客户端和编辑器集成，再回到一个信息更丰富的终端，“对工作流的适配度”是贯穿始终的一贯衡量标准。

关键论点，以及支撑它们的原文

它是怎样运作的

本章论证所依靠的 2 个机制。

常见误读

附录 A的核心概念

面向任务的 Git 工具

为一件事而造的工具，比如查看历史或制作提交，省掉其他一切。

适用处： 只在它狭窄的目的之内有用；更广的工作需要其他客户端。

面向工作流的 Git 客户端

一个暴露精选功能集的客户端，这些功能是为适应某一种工作方式而选的。

适用处： 如果你需要控制网络操作何时发生，就不合适。

GitHub 流程

提交到一个分支，然后经常与远程同步。

适用处： 假定频繁同步；其他分支模型需要不同的习惯。

Shell 的 Git 集成

补全脚本和提示符助手，在 Bash、Zsh 或 PowerShell 里呈现分支和状态信息。

适用处： 随 Git 一起提供，但默认关闭；cmd.exe 无法支持。