Translate 10-git-internals maintenance v2

Author: networm

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

@@ -1,6 +1,6 @@
 === 维护与数据恢复
 
-偶尔，你需要做一些清理 - 使一个仓库体积更小、清理一个导入的仓库、或者恢复丢失的工作。
+偶尔，你必须要做一些清理 - 使一个仓库体积更小、清理一个导入的仓库、或者恢复丢失的工作。
 这个小节将会介绍这些情况中的一些。
 
 [[_git_gc]]
@@ -11,16 +11,16 @@
 然而，如果有太多松散对象（不在打包文件中的对象）或者太多打包文件，Git 运行一个完全的 `git gc` 命令。
 ``gc'' 代表垃圾回收，命令做几件事情：它收集所有松散对象并将它们放置到打包文件中，它将多个打包文件合并为一个大的打包文件，然后移除无法从任何提交追踪到的几个月的对象。
 
-你可以像下面一样手动执行自动垃圾回收：
+可以像下面一样手动执行自动垃圾回收：
 
 [source,console]
 ----
 $ git gc --auto
 ----
 
 再一次，这通常什么事都不做。
-你必须有大约 7000 个松散对象或超过 50 个打包文件 Git 才会启动一次真正的 gc 命令。
-你可以通过 `gc.auto` 与 `gc.autopacklimit` 配置选项分别修改这些限制。
+必须有大约 7000 个松散对象或超过 50 个打包文件 Git 才会启动一次真正的 gc 命令。
+可以通过 `gc.auto` 与 `gc.autopacklimit` 配置选项分别修改这些限制。
 
 `gc` 将会做的另一件事是打包你的引用到一个单独的文件。
 假设你的仓库包含以下分支与标签：
@@ -34,7 +34,7 @@ $ find .git/refs -type f
 .git/refs/tags/v1.1
 ----
 
-如果你运行 `git gc`，在 `refs` 目录中你不会再有这些文件。
+如果运行 `git gc`，在 `refs` 目录中不会再有这些文件。
 Git 会因为缺乏效率而移动进入它们到一个名为 `.git/packed-refs` 的文件，看起来像这样：
 
 [source,console]
@@ -48,19 +48,19 @@ cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
 ^1a410efbd13591db07496601ebc7a059dd55cfe9
 ----
 
-如果你更新一个引用，Git 不会编辑这个文件但是会写一个新文件到 `refs/heads`。
+如果更新一个引用，Git 不会编辑这个文件但是会写一个新文件到 `refs/heads`。
 为了获得给一个给定引用的正确的 SHA，Git 首先在 `refs` 目录中检查那个引用然后作为后备再到 `packed-refs` 文件中检查。
-然而，如果你不能在 `refs` 目录中找到一个引用，它有可能在你的 `packed-refs` 文件中。
+然而，如果不能在 `refs` 目录中找到一个引用，它有可能在你的 `packed-refs` 文件中。
 
 注意文件的最后一行，以 `^` 开头的行。
 这意味着上面的是一个注释标签，那行是注释标签指向的那个提交。
 
 [[_data_recovery]]
 ==== 数据恢复
 
-在你 Git 旅程的某个时候，你可能会意外丢失一次提交。
-通常，这是因为你强制删除了还有工作的分支，原来最终你还想要那个分支；或者你硬重置了一个分支，这样放弃了你想要的提交。
-假设这已经发生，你如何才得得回你的提交呢？
+在你的 Git 旅程的某个时候，你可能会意外丢失一次提交。
+通常，这是因为强制删除了还有工作的分支，原来最终还想要那个分支；或者硬重置了一个分支，这样放弃了你想要的提交。
+假设这已经发生，如何才能得回你的提交呢？
 
 这是一个例子关于在你的 test 仓库中硬重置了 master 分支到一个更老的提交然后恢复丢失的提交。
 首先，让我们看看你的仓库现在在什么地方：
@@ -87,15 +87,15 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-你事实上已经丢失了顶部的两次提交 - 你没有那些提交可到达的分支。
-你需要找出最后一次提交的 SHA 然后增加一个指向它的分支。
+事实上已经丢失了顶部的两次提交 - 没有那些提交可到达的分支。
+需要找出最后一次提交的 SHA 然后增加一个指向它的分支。
 技巧是找到最后一次提交的 SHA - 看起来不像是你还记得它，是吗？
 
 经常，最快捷的方式是使用一个称作 `git reflog` 的工具。
 在你正在工作时，Git 默默地记录每一次你改变 HEAD 时的值。
 每一次你提交或改变分支，引用日志都会被更新。
-引用日志（reflog）也可以通过 `git update-ref` 命令更新，这是另一个原因使用它代替仅仅写入 SHA 值到你的 ref 文件中，如 <<_git_refs>> 我们介绍的。
-你可以在任何时间通过运行 git reflog` 来查看你到过哪里：
+引用日志（reflog）也可以通过 `git update-ref` 命令更新，这是使用它代替仅仅写入 SHA 值到你的 ref 文件中的另一个原因，如 <<_git_refs>> 我们介绍的。
+可以在任何时间通过运行 git reflog` 来查看你到过哪里：
 
 [source,console]
 ----
@@ -128,8 +128,8 @@ Date:   Fri May 22 18:15:24 2009 -0700
        modified repo.rb a bit
 ----
 
-看起来底部的提交是你丢失的那个，所以你可以通过在那次提交上创建一个新分支来恢复它。
-例如，你可以在那次提交（ab1afef）上开始一个名为 `recover-branch` 的新分支：
+看起来底部的提交是你丢失的那个，所以可以通过在那次提交上创建一个新分支来恢复它。
+例如，可以在那次提交（ab1afef）上开始一个名为 `recover-branch` 的新分支：
 
 [source,console]
 ----
@@ -142,8 +142,8 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-酷，现在你有一个名为 `recover-branch` 的分支是你的 `master` 分支曾经指向的地方，再一次使得前两次提交可到达了。
-接下来，假设你的损失因为某些原因不再引用日志中 - 你可以通过移除 `recover-branch` 并删除引用日志来模拟。
+酷，现在有一个名为 `recover-branch` 的分支是你的 `master` 分支曾经指向的地方，再一次使得前两次提交可到达了。
+接下来，假设你的损失因为某些原因不再引用日志中 - 可以通过移除 `recover-branch` 并删除引用日志来模拟。
 现在前两次提交不再可被任何东西到达了：
 
 [source,console]
@@ -152,10 +152,10 @@ $ git branch -D recover-branch
 $ rm -Rf .git/logs/
 ----
 
-因为引用日志数据存放在 `.git/logs/` 目录中，你事实上已经没有引用日志了。
-这时你该如何恢复那次提交？
-一种方式是使用 `git fsck` 实用工具，将会检查你的数据库的完整性。
-如果你使用一个 `--full` 选项运行它，它会向你显示出所有没有被其他对象指向的对象：
+因为引用日志数据存放在 `.git/logs/` 目录中，事实上已经没有引用日志了。
+这时该如何恢复那次提交？
+一种方式是使用 `git fsck` 实用工具，将会检查数据库的完整性。
+如果使用一个 `--full` 选项运行它，它会向你显示出所有没有被其他对象指向的对象：
 
 [source,console]
 ----
@@ -168,8 +168,8 @@ dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
 dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 ----
 
-在本例中，你可以在字符串 ``dangling commit'' 看到你丢失的提交。
-你可以使用同样的方式恢复它，通过添加一个指向那个 SHA 的分支。
+在本例中，可以在字符串 ``dangling commit'' 看到你丢失的提交。
+可以使用同样的方式恢复它，通过添加一个指向那个 SHA 的分支。
 
 [[_removing_objects]]
 ==== 移除对象
@@ -179,15 +179,15 @@ dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 希而，如果某个人在项目历史的任意时间点添加了一个单独的巨大的文件，永久性地每次克隆都被强制下载那个大文件，即使那个文件在接下来的提交中从项目中移除。
 因为它是可以从历史到达的，它会永远在那里。
 
-当你转换 Subversion 或 Perforce 仓库到 Git 时这会是一个巨大的问题。
-因为在那些系统中你并不下载整个历史，这种类型的添加带来的问题较少。
-如果你从另一个系统中导入或因为其他原因发现你的仓库比预期的要大很多，这里就是你如何找到并移除巨大对象的地方。
+当转换 Subversion 或 Perforce 仓库到 Git 时这会是一个巨大的问题。
+因为在那些系统中并不下载整个历史，这种类型的添加带来的问题较少。
+如果从另一个系统中导入或因为其他原因发现仓库比预期的要大很多，这里就是如何找到并移除巨大对象的地方。
 
-*警告：这个技巧对你的提交历史是具有毁灭性的。*
-它会从你必须修改或移除一个大文件引用最早的 tree 对象开始重写每一次提交。
-如果你在导入后马上做这个，在任何人开始基于这些提交工作前，那么很好 - 否则，你必须通知所有贡献者他们必须变基他们的工作到你新的提交上。
+*警告：这个技巧对提交历史是具有毁灭性的。*
+它会从必须修改或移除一个大文件引用最早的 tree 对象开始重写每一次提交。
+如果你在导入后马上做这个，在任何人开始基于这些提交工作前，那么很好 - 否则，你必须通知所有贡献者他们必须变基他们的工作到新的提交上。
 
-为了演示，你将会加添一个大文件到你的 test 仓库，在下一次提交中移除它，找到它，然后从仓库中永久性地移除它。
+为了演示，将会加添一个大文件到你的 test 仓库，在下一次提交中移除它，找到它，然后从仓库中永久性地移除它。
 首先，添加一个大文件到你的历史中：
 
 [source,console]
@@ -213,7 +213,7 @@ $ git commit -m 'oops - removed large tarball'
  delete mode 100644 git.tgz
 ----
 
-现在，`gc` 你的数据库然后看看你使用了多少空间：
+现在，`gc` 数据库然后看看使用了多少空间：
 
 [source,console]
 ----
@@ -225,7 +225,7 @@ Writing objects: 100% (17/17), done.
 Total 17 (delta 1), reused 10 (delta 0)
 ----
 
-你可以运行 `count-objects` 命令来快速查看你使用了多少空间：
+可以运行 `count-objects` 命令来快速查看使用了多少空间：
 
 [source,console]
 ----
@@ -240,16 +240,16 @@ garbage: 0
 size-garbage: 0
 ----
 
-`size-pack` 记录是你的打包文件的千字节大小，所以你使用了大概 5MB。
-在最后一次提交前，你使用了不到 2K - 显然，从之前的提交中移除文件并没有从历史中移除它。
+`size-pack` 记录是你的打包文件的千字节大小，所以使用了大概 5MB。
+在最后一次提交前，使用了不到 2K - 显然，从之前的提交中移除文件并没有从历史中移除它。
 每一次有人克隆这个仓库时，他们将必须克隆所有的 5MB 来获得这个微型项目，因为你意外地添加了一个大文件。
 让我们移除它。
 
 首先你必须找到它。
 在本例中，你已经知道是哪个文件了。
-但是假设你不知道；你该如何找出哪个文件或哪些文件占用了如何多的空间？
-如果你运行 `git gc`，所有的对象都在一个打包文件中；你可以通过运行另一个称作 `git verify-pack` 的底层命令然后对输出的第三列（即文件大小）进行排序，从而找出体积大的对象。
-你也可以通过管道传送给 `tail` 命令，因为你最关心最后的几个最大的文件：
+但是假设你不知道；该如何找出哪个文件或哪些文件占用了如何多的空间？
+如果运行 `git gc`，所有的对象都在一个打包文件中；可以通过运行另一个称作 `git verify-pack` 的底层命令然后对输出的第三列（即文件大小）进行排序，从而找出体积大的对象。
+也可以通过管道传送给 `tail` 命令，因为你最关心最后的几个最大的文件：
 
 [source,console]
 ----
@@ -262,18 +262,18 @@ dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12
 ----
 
 大对象在底部：5MB。
-为了找出是哪个文件，你可以使用 `rev-list` 命令，你在 <<_enforcing_commit_message_format>> 中短暂使用过。
-如果你传递 `--objects` 给 `rev-list`，它会列出所有的提交 SHA 、 blob SHA 与关联到它们的文件路径。
-你可以使用这个来找出你的 blob 的名字：
+为了找出是哪个文件，可以使用 `rev-list` 命令，你在 <<_enforcing_commit_message_format>> 中短暂使用过。
+如果传递 `--objects` 给 `rev-list`，它会列出所有的提交 SHA 、 blob SHA 与关联到它们的文件路径。
+可以使用这个来找出你的 blob 的名字：
 
 [source,console]
 ----
 $ git rev-list --objects --all | grep 82c99a3
 82c99a3e86bb1267b236a4b6eff7868d97489af1 git.tgz
 ----
 
-现在，你需要从你的过去所有的 tree 中移除这个文件。
-你可以轻松地查看哪些提交修改了这个文件：
+现在，需要从你的过去所有的 tree 中移除这个文件。
+可以轻松地查看哪些提交修改了这个文件：
 
 [source,console]
 ----
@@ -282,8 +282,8 @@ dadf725 oops - removed large tarball
 7b30847 add git tarball
 ----
 
-你必须重写 `7b30847` 下流的所有提交来从你的 Git 历史中完全移除这个文件。
-为了这样做，你使用 `filter-branch`，你在 <<_rewriting_history>> 中用过的：
+必须重写 `7b30847` 下流的所有提交来从你的 Git 历史中完全移除这个文件。
+为了这样做，使用 `filter-branch`，你在 <<_rewriting_history>> 中用过的：
 
 [source,console]
 ----
@@ -294,18 +294,18 @@ 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 rm --cached` 来移除一个特定文件，而不是通过类似 `rm file` 的东西来移除它 - 必须从索引中移除它，而不是磁盘中。
 这样做的原因是速度 - 因为 Git 不必在运行你的过滤器前检出每一个版本到磁盘中，这个过程可以非常、非常快。
-如果你愿意的话你也可以通过 `--tree-filter` 来完成同样的任务。
-`git rm` 的 `--ignore-unmatch` 选项告诉它如果你想要尝试删除的模式不在那儿的话不要发生错误。
-最终，你请求 `filter-branch` 来重写自 `6df7640` 以来的历史，因为你知道那是问题开始的地方。
+如果愿意的话也可以通过 `--tree-filter` 来完成同样的任务。
+`git rm` 的 `--ignore-unmatch` 选项告诉它如果想要尝试删除的模式不在那儿的话不要发生错误。
+最终，请求 `filter-branch` 来重写自 `6df7640` 以来的历史，因为你知道那是问题开始的地方。
 否则，它会从头开始然后会不必要的花费更长的时间。
 
 你的历史不再包含对那个文件的引用。
 然而，你的引用日志与你在 `.git/refs/original` 下做的 `filter-branch` 添加的一个新引用还引用着，所以你必须移除它们然后重新打包数据库。
-在你重新打包前你需要移除任何包含指向那些旧提交的指针的东西：
+在重新打包前需要移除任何包含指向那些旧提交的指针的东西：
 
 [source,console]
 ----
@@ -335,8 +335,8 @@ size-garbage: 0
 ----
 
 打包的仓库大小下降到了 8K，比 5MB 好很多。
-你可以从 size 值看到大对象还在你的松散对象中，它并没有消失；但是它不会通过一个推送或接下来的克隆传送，而这是重要的。
-如果你真的想要删除它，你可以通过有 `--expire` 选项的 `git prune` 命令来完全地移除那个对象：
+可以从 size 值看到大对象还在你的松散对象中，它并没有消失；但是它不会通过一个推送或接下来的克隆传送，而这是重要的。
+如果真的想要删除它，可以通过有 `--expire` 选项的 `git prune` 命令来完全地移除那个对象：
 
 [source,console]
 ----