修正第十章破折号

Author: liuxilu

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

@@ -1,6 +1,6 @@
 === 维护与数据恢复
 
-有的时候，你需要对仓库进行清理 - 使它的结构变得更紧凑，或是对导入的仓库进行清理，或是恢复丢失的内容。
+有的时候，你需要对仓库进行清理——使它的结构变得更紧凑，或是对导入的仓库进行清理，或是恢复丢失的内容。
 这个小节将会介绍这些情况中的一部分。
 
 [[r_git_gc]]
@@ -87,9 +87,9 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-现在顶部的两个提交已经丢失了 - 没有分支指向这些提交。
+现在顶部的两个提交已经丢失了——没有分支指向这些提交。
 你需要找出最后一次提交的 SHA-1 然后增加一个指向它的分支。
-窍门就是找到最后一次的提交的 SHA-1 - 但是估计你记不起来了，对吗？
+窍门就是找到最后一次的提交的 SHA-1 ——但是估计你记不起来了，对吗？
 
 最方便，也是最常用的方法，是使用一个名叫 `git reflog` 的工具。
 当你正在工作时，Git 会默默地记录每一次你改变 HEAD 时它的值。
@@ -143,7 +143,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
 不错，现在有一个名为 `recover-branch` 的分支是你的 `master` 分支曾经指向的地方，再一次使得前两次提交可到达了。
-接下来，假设你丢失的提交因为某些原因不在引用日志中 - 我们可以通过移除 `recover-branch` 分支并删除引用日志来模拟这种情况。
+接下来，假设你丢失的提交因为某些原因不在引用日志中——我们可以通过移除 `recover-branch` 分支并删除引用日志来模拟这种情况。
 现在前两次提交又不被任何分支指向了：
 
 [source,console]
@@ -185,7 +185,7 @@ Git 有很多很棒的功能，但是其中一个特性会导致问题，`git cl
 
 *警告：这个操作对提交历史的修改是破坏性的。*
 它会从你必须修改或移除一个大文件引用最早的树对象开始重写每一次提交。
-如果你在导入仓库后，在任何人开始基于这些提交工作前执行这个操作，那么将不会有任何问题 - 否则，你必须通知所有的贡献者他们需要将他们的成果变基到你的新提交上。
+如果你在导入仓库后，在任何人开始基于这些提交工作前执行这个操作，那么将不会有任何问题——否则，你必须通知所有的贡献者他们需要将他们的成果变基到你的新提交上。
 
 为了演示，我们将添加一个大文件到测试仓库中，并在下一次提交中删除它，现在我们需要找到它，并将它从仓库中永久删除。
 首先，添加一个大文件到仓库中：
@@ -200,7 +200,7 @@ $ git commit -m 'add git tarball'
  create mode 100644 git.tgz
 ----
 
-哎呀 - 其实这个项目并不需要这个巨大的压缩文件。
+哎呀——其实这个项目并不需要这个巨大的压缩文件。
 现在我们将它移除：
 
 [source,console]
@@ -241,7 +241,7 @@ size-garbage: 0
 ----
 
 `size-pack` 的数值指的是你的包文件以 KB 为单位计算的大小，所以你大约占用了 5MB 的空间。
-在最后一次提交前，使用了不到 2KB - 显然，从之前的提交中移除文件并不能从历史中移除它。
+在最后一次提交前，使用了不到 2KB ——显然，从之前的提交中移除文件并不能从历史中移除它。
 每一次有人克隆这个仓库时，他们将必须克隆所有的 5MB 来获得这个微型项目，只因为你意外地添加了一个大文件。
 现在来让我们彻底的移除这个文件。
 
@@ -296,8 +296,8 @@ Ref 'refs/heads/master' was rewritten
 
 `--index-filter` 选项类似于在 <<ch07-git-tools#r_rewriting_history>> 中提到的的 `--tree-filter` 选项，不过这个选项并不会让命令将修改在硬盘上检出的文件，而只是修改在暂存区或索引中的文件。
 
-你必须使用 `git rm --cached` 命令来移除文件，而不是通过类似 `rm file` 的命令 - 因为你需要从索引中移除它，而不是磁盘中。
-还有一个原因是速度 - Git 在运行过滤器时，并不会检出每个修订版本到磁盘中，所以这个过程会非常快。
+你必须使用 `git rm --cached` 命令来移除文件，而不是通过类似 `rm file` 的命令——因为你需要从索引中移除它，而不是磁盘中。
+还有一个原因是速度—— Git 在运行过滤器时，并不会检出每个修订版本到磁盘中，所以这个过程会非常快。
 如果愿意的话，你也可以通过 `--tree-filter` 选项来完成同样的任务。
 `git rm` 命令的 `--ignore-unmatch` 选项告诉命令：如果尝试删除的模式不存在时，不提示错误。
 最后，使用 `filter-branch` 选项来重写自 `7b30847` 提交以来的历史，也就是这个问题产生的地方。