修复书中特殊字体渲染问题。 fix #371

Author: ChuckieChen945

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

@@ -218,7 +218,7 @@ $ cat .gitignore
 
 所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。
 星号（`*`）匹配零个或多个任意字符；`[abc]` 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（`?`）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 `[0-9]` 表示匹配所有 0 到 9 的数字）。
-使用两个星号（`*`) 表示匹配任意中间目录，比如`a/**/z` 可以匹配 `a/z`, `a/b/z` 或 `a/b/c/z`等。
+使用两个星号（`*`) 表示匹配任意中间目录，比如 `a/**/z` 可以匹配 `a/z` , `a/b/z` 或 `a/b/c/z` 等。
 
 我们再看一个 .gitignore 文件的例子：
 
@@ -291,7 +291,7 @@ index 8ebb991..643e24f 100644
 -merged in.
 +merged in. Also, split your changes into comprehensive chunks if your patch is
 +longer than a dozen lines.
- 
+
  If you are starting to work on a particular area, feel free to submit a PR
  that highlights your work in progress (and note in the PR title that it's
 ----
@@ -348,7 +348,7 @@ index 643e24f..87f08c8 100644
 +++ b/CONTRIBUTING.md
 @@ -119,3 +119,4 @@ at the
  ## Starter Projects
- 
+
  See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
 +# test line
 ----
@@ -369,7 +369,7 @@ index 8ebb991..643e24f 100644
 -merged in.
 +merged in. Also, split your changes into comprehensive chunks if your patch is
 +longer than a dozen lines.
- 
+
  If you are starting to work on a particular area, feel free to submit a PR
  that highlights your work in progress (and note in the PR title that it's
 ----

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

@@ -221,7 +221,7 @@ image::images/perils-of-rebasing-5.png[在一个被变基然后强制推送的
 
 有一种观点认为，仓库的提交历史即是 *记录实际发生过什么*。
 它是针对历史的文档，本身就有价值，不能乱改。
-从这个角度看来，改变提交历史是一种亵渎，你使用_谎言_掩盖了实际发生过的事情。
+从这个角度看来，改变提交历史是一种亵渎，你使用 _谎言_ 掩盖了实际发生过的事情。
 如果由合并产生的提交历史是一团糟怎么办？
 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。
 

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

@@ -70,7 +70,7 @@ image::images/integration-manager.png[集成管理者工作流。]
 整个流程看起来是这样的(见 <<rwfdiag_c>>):
 
 1.  普通开发者在自己的特性分支上工作，并根据 `master` 分支进行变基。
-    这里是司令官的`master`分支。
+    这里是司令官的 `master` 分支。
 2.  副官将普通开发者的特性分支合并到自己的 `master` 分支中。
 3.  司令官将所有副官的 `master` 分支并入自己的 `master` 分支中。
 4.  司令官将集成后的 `master` 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。

book/06-github/sections/1-setting-up-account.asc

@@ -38,7 +38,7 @@ image::images/account-settings.png[``Account settings''链接。]
 .``SSH keys''链接。
 image::images/ssh-keys.png[``SSH keys''链接。]
 
-在这个页面点击“`Add an SSH key`”按钮，给你的公钥起一个名字，将你的`~/.ssh/id_rsa.pub`（或者自定义的其它名字）公钥文件的内容粘贴到文本区，然后点击``Add key''。
+在这个页面点击“`Add an SSH key`”按钮，给你的公钥起一个名字，将你的 `~/.ssh/id_rsa.pub` （或者自定义的其它名字）公钥文件的内容粘贴到文本区，然后点击``Add key''。
 
 [NOTE]
 ====

book/06-github/sections/3-maintaining.asc

@@ -51,7 +51,7 @@ image::images/reposettingslink.png[版本库设置链接.]
 然后从左侧菜单中选择 ``Collaborators'' 。
 然后，在输入框中填写用户名，点击 ``Add collaborator.''
 如果你想授权给多个人，你可以多次重复这个步骤。
-如果你想收回权限，点击他们同一行右侧的 ``X'' 
+如果你想收回权限，点击他们同一行右侧的 ``X''
 
 .版本库合作者.
 image::images/collaborators.png[版本库合作者.]
@@ -217,7 +217,7 @@ Switched to a new branch 'pr/2'
 这甚至让你可以在按按钮之前就测试这个合并。
 
 
-===== 合并请求之上的合并请求 
+===== 合并请求之上的合并请求
 
 你不仅可以在主分支或者说 `master` 分支上开启合并请求，实际上你可以在网络上的任何一个分支上开启合并请求。
 其实，你甚至可以在另一个合并请求上开启一个合并请求。
@@ -237,7 +237,7 @@ image::images/maint-04-target.png[合并目标]
 
 GitHub 内置了一个很好的通知系统，当你需要与别人或别的团队交流时用起来很方便。
 
-在任何评论中你可以先输入一个`@`，系统会自动补全项目中合作者或贡献者的名字和用户名。
+在任何评论中你可以先输入一个 `@` ，系统会自动补全项目中合作者或贡献者的名字和用户名。
 
 .输入 @ 来提醒某人.
 image::images/maint-05-mentions.png[提醒]
@@ -331,7 +331,7 @@ X-GitHub-Recipient-Address: [email protected]
 * 该项目的作用
 * 如何配置与安装
 * 有关如何使用和运行的例子
-* 项目的许可证 
+* 项目的许可证
 * 如何向项目贡献力量
 
 因为 GitHub 会渲染这个文件，你可以在文件里植入图片或链接让它更容易理解。

book/06-github/sections/4-managing-organization.asc

@@ -54,7 +54,7 @@ image::images/orgs-02-teams.png[团队页面]
 
 当你邀请一个用户加入团队，该用户会收到一封通知他被邀请的邮件。
 
-除此之外，团队也类似于个人帐户，有 `@mentions`（例如：`@acmecorp/frontend`）的功能，不同之处就在于被提及的团队内*所有*成员都会成为这个话题的订阅者。
+除此之外，团队也类似于个人帐户，有 `@mentions`（例如：`@acmecorp/frontend`）的功能，不同之处就在于被提及的团队内 *所有* 成员都会成为这个话题的订阅者。
 当你希望得到团队中某个人的关注，又不知道具体应该问谁的时候，这个功能就显得很有帮助。
 
 一个用户可以加入任意数量的团队，所以别把自己局限于拥有访问控制的团队。

book/07-git-tools/sections/advanced-merging.asc

@@ -17,7 +17,7 @@ Git 的哲学是聪明地决定无歧义的合并方案，但是如果有冲突
 
 首先，在做一次可能有冲突的合并前尽可能保证工作目录是干净的。
 如果你有正在做的工作，要么提交到一个临时分支要么储藏它。
-这使你可以撤消在这里尝试做的*任何事情*。
+这使你可以撤消在这里尝试做的 *任何事情* 。
 如果在你尝试一次合并时工作目录中有未保存的改动，下面的这些技巧可能会使你丢失那些工作。
 
 让我们通过一个非常简单的例子来了解一下。

book/07-git-tools/sections/credentials.asc

@@ -31,7 +31,7 @@ $ git config --global credential.helper cache
 ----
 
 部分辅助工具有一些选项。
-``store'' 模式可以接受一个 `--file <path>` 参数，可以自定义存放密码的文件路径（默认是`~/.git-credentials`）。
+``store'' 模式可以接受一个 `--file <path>` 参数，可以自定义存放密码的文件路径（默认是 `~/.git-credentials` ）。
 ``cache'' 模式有 `--timeout <seconds>` 参数，可以设置后台进程的存活时间（默认是 ``900''，也就是 15 分钟）。
 下面是一个配置 ``store'' 模式自定义路径的例子：
 

book/07-git-tools/sections/stashing-cleaning.asc

@@ -221,8 +221,8 @@ Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
 如果你改变主意了，你也不一定能找回来那些文件的内容。
 一个更安全的选项是运行 `git stash --all` 来移除每一样东西并存放在栈中。
 
-你可以使用`git clean`命令去除冗余文件或者清理工作目录。
-使用`git clean -f -d`命令来移除工作目录中所有未追踪的文件以及空的子目录。
+你可以使用 `git clean` 命令去除冗余文件或者清理工作目录。
+使用 `git clean -f -d` 命令来移除工作目录中所有未追踪的文件以及空的子目录。
 `-f` 意味着 '强制' 或 “确定移除”。
 
 如果只是想要看看它会做什么，可以使用 `-n` 选项来运行命令，这意味着 ``做一次演习然后告诉你 _将要_ 移除什么''。

book/09-git-and-other-scms/sections/import-p4.asc

@@ -68,7 +68,7 @@ Date:   Tue Jul 7 01:35:51 2009 -0800
     [git-p4: depot-paths = "//public/jam/src/": change = 7304]
 ----
 
-你可以看到 `git-p4`在每一个提交里都留下了一个标识符。
+你可以看到 `git-p4` 在每一个提交里都留下了一个标识符。
 如果之后想要引用 Perforce 的修改序号的话，标识符保留在那里也是可以的。
 然而，如果想要移除标识符，现在正是这么做的时候 - 在你开始在新仓库中工作之前。
 (((git commands, filter-branch)))