Fixes links

Author: OlingCat

C-git-commands.asc

@@ -74,7 +74,7 @@ Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值
 就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。
 
 这使得我们使用 Git 成为一个安心愉悦的过程，因为我们深知可以尽情做各种尝试，而没有把事情弄糟的危险。
-更深度探讨 Git 如何保存数据及恢复丢失数据的话题，请参考<<ch02-git-basics#_undoing>>。
+更深度探讨 Git 如何保存数据及恢复丢失数据的话题，请参考<<ch02-git-basics-chapter#_undoing>>。
 
 ==== 三种状态
 
@@ -109,5 +109,5 @@ Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地
 如果 Git 目录中保存着特定版本的文件，就属于 *已提交* 状态。
 如果文件已修改并放入暂存区，就属于 *已暂存* 状态。
 如果自上次检出后，作了修改但还没有放到暂存区域，就是 *已修改* 状态。
-在 <<ch02-git-basics#ch02-git-basics>> 一章，你会进一步了解这些状态的细节，
+在 <<ch02-git-basics-chapter#ch02-git-basics-chapter>> 一章，你会进一步了解这些状态的细节，
 并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。

book/01-introduction/sections/what-is-git.asc

@@ -61,7 +61,7 @@ $ git commit -m 'initial project version'
 这是 Git 区别于其它版本控制系统的一个重要特性，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。
 当你执行 `git clone` 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库
-（虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在，详见 <<ch04-git-server#_git_on_the_server>> ）。
+（虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在，详见 <<ch04-git-on-the-server#_getting_git_on_a_server>> ）。
 
 克隆仓库的命令是 `git clone <url>` 。(((git commands, clone)))
 比如，要克隆 Git 的链接库 `libgit2`，可以用下面的命令：
@@ -86,4 +86,4 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit
 
 Git 支持多种数据传输协议。
 上面的例子使用的是 `https://` 协议，不过你也可以使用 `git://` 协议或者使用 SSH 传输协议，比如 `user@server:path/to/repo.git` 。
-<<ch04-git-server#_git_on_the_server>> 将会介绍所有这些协议在服务器端如何配置使用，以及各种方式之间的利弊。
+<<ch04-git-on-the-server#_getting_git_on_a_server>> 将会介绍所有这些协议在服务器端如何配置使用，以及各种方式之间的利弊。

book/02-git-basics/sections/getting-a-repository.asc

@@ -431,7 +431,7 @@ $ git commit
 [NOTE]
 ====
 启动的编辑器是通过 Shell 的环境变量 `EDITOR` 指定的，一般为 vim 或 emacs。
-当然也可以按照 <<ch01-introduction#ch01-introduction>> 介绍的方式，
+当然也可以按照 <<ch01-getting-started#ch01-getting-started>> 介绍的方式，
 使用 `git config --global core.editor` 命令设置你喜欢的编辑器。
 (((editor, changing default)))(((git commands, config)))
 ====

book/02-git-basics/sections/recording-changes.asc

@@ -66,7 +66,7 @@ origin    [email protected]:mojombo/grit.git (push)
 
 这表示我们能非常方便地拉取其它用户的贡献。我们还可以拥有向他们推送的权限，这里暂不详述。
 
-注意这些远程仓库使用了不同的协议。我们将会在 <<ch04-git-server#_git_on_the_server>> 中了解关于它们的更多信息。
+注意这些远程仓库使用了不同的协议。我们将会在 <<ch04-git-on-the-server#_getting_git_on_a_server>> 中了解关于它们的更多信息。
 
 ==== 添加远程仓库
 

book/02-git-basics/sections/remotes.asc

@@ -3,7 +3,7 @@
 
 为了真正理解 Git 处理分支的方式，我们需要回顾一下 Git 是如何保存数据的。
 
-或许你还记得 <<ch01-introduction#ch01-introduction>> 的内容，
+或许你还记得 <<ch01-getting-started#ch01-getting-started>> 的内容，
 Git 保存的不是文件的变化或者差异，而是一系列不同时刻的 *快照* 。
 
 在进行提交操作时，Git 会保存一个提交对象（commit object）。
@@ -13,7 +13,7 @@ Git 保存的不是文件的变化或者差异，而是一系列不同时刻的
 而由多个分支合并产生的提交对象有多个父对象，
 
 为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。
-暂存操作会为每一个文件计算校验和（使用我们在 <<ch01-introduction#ch01-introduction>>
+暂存操作会为每一个文件计算校验和（使用我们在 <<ch01-getting-started#ch01-getting-started>>
 中提到的 SHA-1 哈希算法），然后会把当前版本的文件快照保存到 Git 仓库中
 （Git 使用 _blob_ 对象来保存它们），最终将校验和加入到暂存区域等待提交：
 

book/03-git-branching/sections/nutshell.asc

@@ -67,12 +67,12 @@ image::images/basic-rebase-4.png[`master` 分支的快进合并。]
 ==== 更有趣的变基例子
 
 在对两个分支进行变基时，所生成的“重放”并不一定要在目标分支上应用，你也可以指定另外的一个分支进行应用。
-就像 <<rbdiag_e>> 中的例子那样。
+就像 <<bdiag_e>> 中的例子那样。
 你创建了一个主题分支 `server`，为服务端添加了一些功能，提交了 `C3` 和 `C4`。
 然后从 `C3` 上创建了主题分支 `client`，为客户端添加了一些功能，提交了 `C8` 和 `C9`。
 最后，你回到 `server` 分支，又提交了 `C10`。
 
-[[rbdiag_e]]
+[[bdiag_e]]
 .从一个主题分支里再分出一个主题分支的提交历史
 image::images/interesting-rebase-1.png[从一个主题分支里再分出一个主题分支的提交历史。]
 
@@ -91,15 +91,15 @@ $ git rebase --onto master server client
 .截取主题分支上的另一个主题分支，然后变基到其他分支
 image::images/interesting-rebase-2.png[截取主题分支上的另一个主题分支，然后变基到其他分支。]
 
-现在可以快进合并 `master` 分支了。（如图 <<rbdiag_g>>）：
+现在可以快进合并 `master` 分支了。（如图 <<bdiag_g>>）：
 
 [source,console]
 ----
 $ git checkout master
 $ git merge client
 ----
 
-[[rbdiag_g]]
+[[bdiag_g]]
 .快进合并 `master` 分支，使之包含来自 `client` 分支的修改
 image::images/interesting-rebase-3.png[快进合并 `master` 分支，使之包含来自 `client` 分支的修改。]
 
@@ -113,9 +113,9 @@ image::images/interesting-rebase-3.png[快进合并 `master` 分支，使之包
 $ git rebase master server
 ----
 
-如图 <<rbdiag_h>> 所示，`server` 中的代码被“续”到了 `master` 后面。
+如图 <<bdiag_h>> 所示，`server` 中的代码被“续”到了 `master` 后面。
 
-[[rbdiag_h]]
+[[bdiag_h]]
 .将 `server` 中的修改变基到 `master` 上
 image::images/interesting-rebase-4.png[将 `server` 中的修改变基到 `master` 上。]
 
@@ -128,15 +128,15 @@ $ git merge server
 ----
 
 至此，`client` 和 `server` 分支中的修改都已经整合到主分支里了，
-你可以删除这两个分支，最终提交历史会变成图 <<rbdiag_i>> 中的样子：
+你可以删除这两个分支，最终提交历史会变成图 <<bdiag_i>> 中的样子：
 
 [source,console]
 ----
 $ git branch -d client
 $ git branch -d server
 ----
 
-[[rbdiag_i]]
+[[bdiag_i]]
 .最终的提交历史
 image::images/interesting-rebase-5.png[最终的提交历史。]
 

book/03-git-branching/sections/rebasing.asc

@@ -51,7 +51,7 @@ image::images/remote-branches-3.png[`git fetch` 更新你的远程仓库引用
 为了演示有多个远程仓库与远程分支的情况，我们假定你有另一个内部 Git 服务器，仅服务于你的某个敏捷开发团队。
 这个服务器位于 `git.team1.ourcompany.com`。
 你可以运行 `git remote add` 命令添加一个新的远程仓库引用到当前的项目，这个命令我们会在
-<<ch02-git-basics#ch02-git-basics>> 中详细说明。
+<<ch02-git-basics-chapter#ch02-git-basics-chapter>> 中详细说明。
 将这个远程仓库命名为 `teamone`，将其作为完整 URL 的缩写。
 
 .添加另一个远程仓库

book/03-git-branching/sections/remote-branches.asc

@@ -447,7 +447,7 @@ $ git config --global rerere.enabled true
 当单独调用它时，Git 会检查解决方案数据库，尝试寻找一个和当前任一冲突相关的匹配项并解决冲突
 （尽管当 `rerere.enabled` 被设置为 `true` 时会自动进行）。
 它也有若干子命令，可用来查看记录项，删除特定解决方案和清除缓存全部内容等。
-我们将在 <<ch07-git-tools#_rerere>> 中详细探讨。
+我们将在 <<ch07-git-tools#ef_rerere>> 中详细探讨。
 
 [[_tagging_releases]]
 ==== 为发布打标签

book/05-distributed-git/sections/maintaining.asc

@@ -95,14 +95,14 @@ $ curl https://github.com/tonychacon/fade/pull/1.patch | git am
 
 ===== 在合并请求上进行合作
 
-就像我们在 <<ch06-github#ch06-github_flow>> 中说过的，现在你可以跟开启合并请求的人进行会话。
+就像我们在 <<ch06-github#_github_flow>> 中说过的，现在你可以跟开启合并请求的人进行会话。
 你既可以对某些代码添加注释，也可以对整个提交添加注释或对整个合并请求添加注释，
-在任何地方都可以用 GitHub Flavored Markdown。
+在任何地方都可以用 GitHub 风格的 Markdown。
 
 每次有人在合并请求上进行注释你都会收到通知邮件，通知你哪里发生改变。
 他们都会包含一个到改变位置的链接，你可以直接在邮件中对合并请求进行注释。
 
-.Responses to emails are included in the thread.
+.回复邮件会包含在线索（tread）中。
 image::images/maint-03-email-resp.png[邮件回复]
 
 一旦代码符合了你的要求，你想把它合并进来，你可以把代码拉取下来在本地进行合并，也可以用我们之前提到过的 `git pull <url> <branch>` 语法，或者把 fork 添加为一个 remote，然后进行抓取和合并。