解决ISSUE 427、ISSUE 424、ISSUE 423、ISSUE 422

Author: ZhangJinbao520

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

@@ -1,7 +1,7 @@
 === 记录每次更新到仓库
 
 现在我们的机器上有了一个 *真实项目* 的 Git 仓库，并从这个仓库中检出了所有文件的 *工作副本*。
-通常，你会对这些文件做些修改，每当完成了一个阶段的目标，想要将记录下它时，就将它提交到到仓库。
+通常，你会对这些文件做些修改，每当完成了一个阶段的目标，想要将记录下它时，就将它提交到仓库。
 
 请记住，你工作目录下的每一个文件都不外乎这两种状态：*已跟踪* 或 *未跟踪*。
 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，
@@ -626,5 +626,6 @@ $ git add README
 ----
 
 如此分开操作，Git 也会意识到这是一次重命名，所以不管何种方式结果都一样。
-两者唯一的区别是，`mv` 是一条命令而非三条命令，直接用 `git mv` 方便得多。
-不过有时候用其他工具批处理重命名的话，要记得在提交前删除旧的文件名，再添加新的文件名。
+两者唯一的区别在于，`git mv` 是一条命令而非三条命令，直接使用 `git mv` 方便得多。
+不过在使用其他工具重命名文件时，记得在提交前 `git mv` 删除旧文件名，再 `git add` 
+添加新文件名。

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

@@ -34,7 +34,7 @@ $ git commit --amend
 
 [NOTE]
 ====
-当你在修补最后的提交时，并不是通过用改进后的提交 *原位替换* 掉旧有提交的方式来修复的，
+当你在修补最后的提交时，与其说是修复旧提交，倒不如说是完全用一个 *新的提交* 替换旧的提交，
 理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。
 
 修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者

book/02-git-basics/sections/viewing-history.asc

@@ -246,9 +246,9 @@ $ git log --since=2.weeks
 
 [NOTE]
 ====
-你可以指定多个 `--author` 和 `--grep` 搜索条件，这样会只输出 *任意* 匹配
-`--author` 模式和 `--grep` 模式的提交。然而，如果你添加了 `--all-match` 选项，
-则只会输出 *所有* 匹配 `--grep` 模式的提交。
+你可以指定多个 `--author` 和 `--grep` 搜索条件，这样会只输出匹配 *任意* 
+`--author` 模式和 *任意* `--grep` 模式的提交。然而，如果你添加了 `--all-match` 选项，
+则只会输出匹配 *所有* `--grep` 模式的提交。
 ====
 
 另一个非常有用的过滤器是 `-S`（俗称“pickaxe”选项，取“用鹤嘴锄在土里捡石头”之意），