Review 10-git-internals maintenance v3

Author: networm

book/10-git-internals/sections/maintenance.asc

@@ -6,7 +6,7 @@
 [[_git_gc]]
 ==== 维护
 
-Git 会不定时的自动运行一个叫做 ``auto gc'' 的命令。
+Git 会不定时地自动运行一个叫做 ``auto gc'' 的命令。
 大多数时候，这个命令并不会产生效果。
 然而，如果有太多松散对象（不在包文件中的对象）或者太多包文件，Git 会运行一个完整的 `git gc` 命令。
 ``gc'' 代表垃圾回收，这个命令会做以下事情：收集所有松散对象并将它们放置到包文件中，将多个包文件合并为一个大的包文件，移除与任何提交都不相关的陈旧对象。
@@ -91,8 +91,8 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 你需要找出最后一次提交的 SHA 然后增加一个指向它的分支。
 窍门就是找到最后一次的提交的 SHA - 但是估计你记不起来了，对吗？
 
-最常用，且最方便的方法，是使用一个名叫 `git reflog` 的工具。
-当你正在工作时，Git 会默默地记录每一次你改变 HEAD 时的值。
+最方便，也是最常用的方法，是使用一个名叫 `git reflog` 的工具。
+当你正在工作时，Git 会默默地记录每一次你改变 HEAD 时它的值。
 每一次你提交或改变分支，引用日志都会被更新。
 引用日志（reflog）也可以通过 `git update-ref` 命令更新，我们在 <<_git_refs>> 有提到使用这个命令而不是是直接将 SHA 的值写入引用文件中的原因。
 你可以在任何时候通过执行 `git reflog` 命令来了解你曾经做过什么：
@@ -105,7 +105,7 @@ ab1afef HEAD@{1}: commit: modified repo.rb a bit
 484a592 HEAD@{2}: commit: added repo.rb
 ----
 
-这里可以看到我们已经检出的两次提交，然而这里没有足够多的信息。
+这里可以看到我们已经检出的两次提交，然而并没有足够多的信息。
 为了使显示的信息更加有用，我们可以执行 `git log -g`，这个命令会以标准日志的格式输出引用日志。
 
 [source,console]
@@ -142,7 +142,7 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-酷，现在有一个名为 `recover-branch` 的分支是你的 `master` 分支曾经指向的地方，再一次使得前两次提交可到达了。
+不错，现在有一个名为 `recover-branch` 的分支是你的 `master` 分支曾经指向的地方，再一次使得前两次提交可到达了。
 接下来，假设你丢失的提交因为某些原因不在引用日志中 - 我们可以通过移除 `recover-branch` 分支并删除引用日志来模拟这种情况。
 现在前两次提交又不被任何分支指向了：
 
@@ -294,7 +294,7 @@ Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 (2/2)
 Ref 'refs/heads/master' was rewritten
 ----
 
-`--index-filter` 选项类似于在 <<_rewriting_history>> 中提到的的 `--tree-filter` 选项，不过这个选项并不会让命令将修改在硬盘上检出的文件，而是修改在暂存区或索引中的文件。
+`--index-filter` 选项类似于在 <<_rewriting_history>> 中提到的的 `--tree-filter` 选项，不过这个选项并不会让命令将修改在硬盘上检出的文件，而只是修改在暂存区或索引中的文件。
 
 你必须使用 `git rm --cached` 命令来移除文件，而不是通过类似 `rm file` 的命令 - 因为你需要从索引中移除它，而不是磁盘中。
 还有一个原因是速度 - Git 在运行过滤器时，并不会检出每个修订版本到磁盘中，所以这个过程会非常快。