add whitespace around * to avoid asciidoc transform bug

Author: spacewander

book/01-introduction/sections/command-line.asc

@@ -3,7 +3,7 @@
 Git 有多种使用方式。
 你可以使用原生的命令行模式，也可以使用 GUI 模式，这些 GUI 软件也能提供多种功能。
 在本书中，我们将使用命令行模式。
-这是因为首先，只有在命令行模式下你才能执行 Git 的*所有*命令，而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度。
+这是因为首先，只有在命令行模式下你才能执行 Git 的 *所有* 命令，而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度。
 如果你学会了在命令行下如何操作，那么你在操作 GUI 软件时应该也不会遇到什么困难，但是，反之则不成立。
 此外，由于每个人的想法与侧重点不同，不同的人常常会安装不同的 GUI 软件，但_所有_人一定会有命令行工具。
 

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

@@ -179,7 +179,7 @@ image::images/perils-of-rebasing-4.png[你将相同的内容又合并了一次
 [[_rebase_rebase]]
 ==== 用衍合解决衍合
 
-如果你*真的*遭遇了类似的处境，Git 还有一些高级魔法可以帮到你。如果团队中的某人强制推送并覆盖了一些你所基于的提交，你需要做的就是检查你做了哪些修改，以及他们覆盖了哪些修改。
+如果你 *真的* 遭遇了类似的处境，Git 还有一些高级魔法可以帮到你。如果团队中的某人强制推送并覆盖了一些你所基于的提交，你需要做的就是检查你做了哪些修改，以及他们覆盖了哪些修改。
 
 实际上，Git 除了对整个提交计算 SHA 校验和以外，也对本次提交所引入的修改计算了校验和——即 ``patch-id''。
 
@@ -215,13 +215,13 @@ image::images/perils-of-rebasing-5.png[在一个被衍合然后强制推送的
 至此，你已在实战中学习了衍合和合并的用法，你一定会想问，到底哪种方式更好。
 在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。
 
-有一种观点认为，仓库的提交历史即是*记录实际发生过什么*。
+有一种观点认为，仓库的提交历史即是 *记录实际发生过什么*。
 它是针对历史的文档，本身就有价值，不能乱改。
 从这个角度看来，改变提交历史是一种亵渎，你使用_谎言_掩盖了实际发生过的事情。
 如果由合并产生的提交历史是一团糟怎么办？
 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。
 
-另一种观点则正好相反，他们认为提交历史是*项目过程中发生的故事*。
+另一种观点则正好相反，他们认为提交历史是 *项目过程中发生的故事*。
 没人会出版一本书的第一批草稿，软件维护手册也是需要反复修订才能方便使用。
 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。