add references to other chapters

01-meet-git/020-love-git.rst

@@ -32,6 +32,8 @@
 
 从图2-1中可以看出，我的每日工作保存有三个拷贝，一个在笔记本中，一个在公内网的服务器上，还有一个在外网的镜像版本库中。鸡蛋装在了三个篮子里。
 
+至于如何架设可以实时镜像的 Git 服务器，会在本书第5篇第30章介绍。
+
 异地协同工作
 ===========================
 
@@ -77,6 +79,8 @@
 
 而我只要执行 `git pull` 操作就可以获得小崔对我文稿的修订（图2-2中步骤8）。采用这种工作方式，文稿竟然拥有6个拷贝，真可谓狡兔三窟。不，比狡兔还要多三窟。
 
+在本节出现在 git 命令中的 `mirror` 和 `home` 是和工作区关联的远程版本库。关于如何注册和使用远程版本库，参见本书第3篇第19章的内容。
+
 现场版本控制
 =============
 
@@ -117,17 +121,17 @@
 
     $ svn diff -r1 > hacks.patch
 
-但是 SVN 的补丁文件不支持二进制文件，因此采用补丁文件的方式有可能丢失数据。更为稳妥但也更为复杂的方式可能要用到 svnadmin dump 命令，如下：
+但是 SVN 的补丁文件不支持二进制文件，因此采用补丁文件的方式有可能丢失数据。更为稳妥但也更为复杂的方式可能要用到 svnadmin 命令将版本库导出。如下：
 
 ::
 
   $ svnadmin dump --incremental -r2:HEAD /path/to/repos/project1/ > hacks.dump
 
-但是通过导出文件逐一恢复提交也是一件麻烦事。还是来看看 Git 在这种情况下的表现吧。
+将 svnadmin 命令创建的导出文件恢复到版本库中也非常具有挑战性，就不再详细说明了。还是来看看 Git 在这种情况下的表现吧。
 
 **Git 的解决方案**
 
-Git 对产品部署目录进行到工作区的转化相比 SVN 要更为简单，而且将历次提交导出为补丁文件，Git 的方法也更为简练和实用。
+Git 对产品部署目录进行到工作区的转化相比 SVN 要更为简单，而且使用 Git 将提交历史导出也更为简练和实用。
 
 * 现场版本库创建。直接在需要版本控制的目录下执行 Git 版本库初始化命令。
 
@@ -142,54 +146,57 @@ Git 对产品部署目录进行到工作区的转化相比 SVN 要更为简单
     $ git add -A
     $ git commit -m "initialized"
 
-* 为初始版本建立一个里程碑。
+* 为初始提交建立一个里程碑：“v1”。
 
   ::
 
-    $ git tag v1.0
+    $ git tag v1
 
-* 然后开始在工作区中修改文件，提交。
+* 然后开始在工作区中工作 —— 修改文件，提交。
 
   ::
 
     $ git commit -a
 
-* 当对修改结果满意，想将工作成果保存带走，可以通过下面的命令将从 v1.0 开始的历次提交逐一导出为补丁文件。转换的补丁文件都包含一个数字前缀，并提取提交日志信息作为文件名。而且补丁文件还提供对二进制文件的支持。下面命令的输出摘自本书中的实例。
+* 当对修改结果满意，想将工作成果保存带走，可以通过下面的命令将从 v1 开始的历次提交逐一导出为补丁文件。转换的补丁文件都包含一个数字前缀，并提取提交日志信息作为文件名。而且补丁文件还提供对二进制文件的支持。下面命令输出摘自本书第20章中的实例。
 
   ::
 
-    $ git format-patch v1.0..HEAD
+    $ git format-patch v1..HEAD
     0001-Fix-typo-help-to-help.patch
     0002-Add-I18N-support.patch
     0003-Translate-for-Chinese.patch
 
-* 通过邮件将补丁文件发出。
+* 通过邮件将补丁文件发出。当然也可以通过其他方式将补丁文件带走。
 
   ::
 
     $ git send-email *.patch
 
+Git 创建的补丁文件包含了 Git 扩展格式，因此在导入时为了避免数据遗漏，要使用 Git 提供的命令而不能使用 GNU patch 命令。即使要导入的不是 Git 版本库，也可以使用 Git 命令，具体操作请参见本书第38章。
+
+
 避免引入辅助目录
 =================
 
 很多版本控制系统，都要在工作区中引入辅助目录或文件，如SVN要在工作区的每一个子目录下都创建 `.svn` 目录，CVS要在工作区的每一个子目录下都创建 `CVS` 目录。
 
-这些辅助目录如果出现在服务器尤其是Web服务器上是危险的，会因为这些辅助目录下的 `Entries` 文件暴露出目录下的文件列表，让管理员精心配置的禁止目录浏览的努力白费。
+这些辅助目录如果出现在服务器尤其是Web服务器上是危险的，会因为这些辅助目录下的 `Entries` 文件会暴露出目录下的文件列表，让管理员精心配置的禁止目录浏览的努力白费。
 
-还有SVN的 `.svn` 辅助目录下还存在文件的原始拷贝，在文件搜索时结果会加倍。如果读者曾经在SVN的工作区用过 `grep` 命令进行内容查找，就会明白指的是什么。
+还有SVN的 `.svn` 辅助目录下还存在文件的原始拷贝，在文件搜索时结果会加倍。如果读者曾经在SVN的工作区用过 `grep` 命令进行内容查找，就会明白我指的是什么。
 
-Git没有这个问题，不会在子目录下引入讨厌的辅助目录或文件（ `.gitignore` 文件不算）。当然Git还是要在工作区的顶级目录下创建名为 `.git` 的目录（版本库目录），不过如果你认为唯一的一个 `.git` 目录也过于碍眼，你将其放到工作区之外的任意目录。一旦这么做了，你在执行Git命令时，要通过命令行（ `--git-dir=` ）或环境变量 `GIT_DIR` 为工作区指定版本库目录，甚至还有指定工作区目录。
+Git没有这个问题，不会在子目录下引入讨厌的辅助目录或文件（ `.gitignore` 文件不算）。当然Git还是要在工作区的顶级目录下创建名为 `.git` 的目录（版本库目录），不过如果你认为唯一的一个 `.git` 目录也过于碍眼，你将其放到工作区之外的任意目录。一旦这么做了，你在执行Git命令时，要通过命令行（ `--git-dir` ）或环境变量 `GIT_DIR` 为工作区指定版本库目录，甚至还要指定工作区目录。
 
-Git 还转门提供了一个 `git grep` 命令，这样在工作区根目录下执行查找时，目录 `.git` 也不会对搜索造成影响。
+Git 还专门提供了一个 `git grep` 命令，这样在工作区根目录下执行查找时，目录 `.git` 也不会对搜索造成影响。关于辅助目录的详悉讨论参见本书第4章第4.2节的内容。
 
 重写提交说明
 ==============
 
-很多人，可能如我一样，在敲下回车之后，才发现提交说明中出现了错别字，或忘记了写关联的 BugID。这就需要重写提交说明。
+很多人可能如我一样，在敲下回车之后，才发现提交说明中出现了错别字，或忘记了写关联的 BugID。这就需要重写提交说明。
 
 **SVN 的解决方案**
 
-SVN的提交说明默认是禁止更改的，因为SVN的提交说明属于不受版本控制的属性，一旦修改不可恢复。我建议SVN管理员只有在配置了版本库更改外发通知邮件之后，才开放提交说明更改的功能。我发布于 SourceForge 上的 pySvnManager 项目，提供了SVN版本库图形化的钩子管理，会简化管理员的配置工作。
+SVN的提交说明默认是禁止更改的，因为SVN的提交说明属于不受版本控制的属性，一旦修改不可恢复。我建议SVN管理员只有在配置了版本库更改的外发邮件通知之后，才开放提交说明更改的功能。我发布于 SourceForge 上的 pySvnManager 项目，提供了SVN版本库图形化的钩子管理，会简化管理员的配置工作。
 
 在SVN管理员打开了提交说明更改的设置后，修改提交说明也是挺复杂的，看看下面的命令：
 
@@ -213,6 +220,7 @@ Git 修改提交说明很简单，而且提交说明的修改也是被追踪的
 
   $ git rebase -i <commit-id>^
 
+关于如何使用交互式变基操作更改历史提交的提交说明，参见本书第12章的内容。
 
 想吃后悔药
 ============
@@ -248,7 +256,7 @@ SVN 遇到这个问题该怎么办呢？删除错误加入的大文件，再提
 
   $ git rebase -i <commit-id>^
 
-关于交互式变基的具体操作细节，参见本书相关章节。
+执行交互式变基操作抛弃历史提交，版本库还不能立即瘦身，具体原因和解决方案参见本书第14章的内容。除了使用变基操作，Git 还有更多的武器实现版本库的整理操作，参见本书第35章第35.4节的内容。
 
 更好用的提交列表
 ======================
@@ -277,7 +285,7 @@ Git 通过提交暂存区实现对提交内容的定制，非常完美的实现
 * 执行 `git commit` 命令提交，无需设定什么变更列表，直接将登记在暂存区中的内容提交。
 * Git 支持对提交的撤消，而且可以撤消任意多次。
 
-只要使用 Git，就会时刻在和隐形的提交列表打交道，你会爱上 Git 的这个特性。
+只要使用 Git，就会时刻在和隐形的提交列表打交道。本书第5章“Git暂存区”会详细介绍 Git 的这一特性，相信你会爱上 Git 的这个特性。
 
 更好的差异比较
 =================
@@ -291,7 +299,7 @@ Git 对差异比较进行了扩展的支持，可以在差异文件中包含二
 * 当继续对此文件进行修改，再执行 `git diff` 命令，会看到新的修改显示在差异中，而旧的修改看不到。
 * 执行 `git diff --cached` 命令才可以看到添加到暂存区的文件所做出的修改。
 
-Git 的差异比较的命令充满了魔法，本书会有相关章节详悉剖析。一旦用户习惯了，会非常喜欢 `git diff` 的这个行为。
+Git 的差异比较的命令充满了魔法，本书第5章第5.3节会带您破解 Git 的 diff 魔法。一旦用户习惯了，会非常喜欢 `git diff` 的这个行为。
 
 工作进度保存
 ==============
@@ -336,7 +344,7 @@ Git 提供了一个可以保存和恢复工作进度的命令 `git stash` 。非
   $ git checkout <orignal_branch>
   $ git stash pop
 
-在本书后面的章节会为您揭开 `git stash` 命令的奥秘。
+在本书第9章“恢复进度”会为您揭开 `git stash` 命令的奥秘。
 
 代理SVN提交实现移动式办公
 ==========================
@@ -363,6 +371,8 @@ Git 提供了一个可以保存和恢复工作进度的命令 `git stash` 。非
     $ git svn rebase
     $ git svn dcommit
 
+本书第4篇第26章会详细介绍这一话题。
+
 无处不在的分页器
 ==================