Merge pull request #170 from networm/07-git-tools_rerere

Translate 07-git-tools rerere

book/07-git-tools/sections/rerere.asc

@@ -1,24 +1,24 @@
 [[_rerere]]
 === Rerere
 
-The `git rerere` functionality is a bit of a hidden feature.  The name stands for ``reuse recorded resolution'' and as the name implies, it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you.
+`git rerere` 功能是一个隐藏的功能。正如它的名字 ``reuse recorded resolution'' 所指，它允许你让 Git 记住解决一个块冲突的方法，这样在下一次看到相同冲突时，Git 可以为你自动地解决它。
 
-There are a number of scenarios in which this functionality might be really handy. One of the examples that is mentioned in the documentation is if you want to make sure a long lived topic branch will merge cleanly but don't want to have a bunch of intermediate merge commits. With `rerere` turned on you can merge occasionally, resolve the conflicts, then back out the merge. If you do this continuously, then the final merge should be easy because `rerere` can just do everything for you automatically.
+有几种情形下这个功能会非常有用。在文档中提到的一个例子是如果你想要保证一个长期分支会干净地合并，但是又不想要一串中间的合并提交。将 `rerere` 功能打开后偶尔合并，解决冲突，然后返回到合并前。如果你持续这样做，那么最终的合并会很容易，因为 `rerere` 可以为你自动做所有的事情。
 
-This same tactic can be used if you want to keep a branch rebased so you don't have to deal with the same rebasing conflicts each time you do it.  Or if you want to take a branch that you merged and fixed a bunch of conflicts and then decide to rebase it instead - you likely won't have to do all the same conflicts again.
+可以将同样的策略用在维持一个变基的分支时，这样就不用每次解决同样的变基冲突了。或者你将一个分支合并并修复了一堆冲突后想要用变基来替代合并 - 你可能并不想要再次解决相同的冲突。
 
-Another situation is where you merge a bunch of evolving topic branches together into a testable head occasionally, as the Git project itself often does. If the tests fail, you can rewind the merges and re-do them without the topic branch that made the tests fail without having to re-resolve the conflicts again.
+另一个情形是当你偶尔将一堆正在改进的特性分支合并到一个可测试的头时，就像 Git 项目自身经常做的。如果测试失败，你可以倒回合并之前然后在去除导致测试失败的那个特性分支后重做合并，而不用再次重新解决所有的冲突。
 
-To enable the `rerere` functionality, you simply have to run this config setting:
+为了启用 `rerere` 功能，仅仅需要运行这个配置选项：
 
 [source,console]
 ----
 $ git config --global rerere.enabled true
 ----
 
-You can also turn it on by creating the `.git/rr-cache` directory in a specific repository, but the config setting is clearer and it can be done globally.
+也通过在特定的仓库中创建 `.git/rr-cache` 目录来开启它，但是设置选项更干净并且可以应用到全局。
 
-Now let's see a simple example, similar to our previous one. Let's say we have a file that looks like this:
+现在我们看一个简单的例子，类似之前的那个。假设有一个像这样的文件：
 
 [source,console]
 ----
@@ -29,11 +29,11 @@ def hello
 end
 ----
 
-In one branch we change the word ``hello'' to ``hola'', then in another branch we change the ``world'' to ``mundo'', just like before.
+在一个分支中修改单词 ``hello'' 为 ``hola''，然后在另一个分支中修改 ``world'' 为 ``mundo''，就像之前一样。
 
 image::images/rerere1.png[]
 
-When we merge the two branches together, we'll get a merge conflict:
+当合并两个分支到一起时，我们将会得到一个合并冲突：
 
 [source,console]
 ----
@@ -44,7 +44,7 @@ Recorded preimage for 'hello.rb'
 Automatic merge failed; fix conflicts and then commit the result.
 ----
 
-You should notice the new line `Recorded preimage for FILE` in there. Otherwise it should look exactly like a normal merge conflict. At this point, `rerere` can tell us a few things. Normally, you might run `git status` at this point to see what all conflicted:
+你会注意到那个新行 `Recorded preimage for FILE`。除此之外它应该看起来就像一个普通的合并冲突。在这个时候，`rerere` 可以告诉我们几件事。和往常一样，在这个时候你可以运行 `git status` 来查看所有冲突的内容：
 
 [source,console]
 ----
@@ -58,15 +58,15 @@ $ git status
 #
 ----
 
-However, `git rerere` will also tell you what it has recorded the pre-merge state for with `git rerere status`:
+然而，`git rerere` 也会通过 `git rerere status` 告诉你它记录的合并前状态。
 
 [source,console]
 ----
 $ git rerere status
 hello.rb
 ----
 
-And `git rerere diff` will show the current state of the resolution - what you started with to resolve and what you've resolved it to.
+并且 `git rerere diff` 将会显示解决方案的当前状态 - 开始解决前与解决后的样子。
 
 [source,console]
 ----
@@ -89,7 +89,7 @@ $ git rerere diff
  end
 ----
 
-Also (and this isn't really related to `rerere`), you can use `ls-files -u` to see the conflicted files and the before, left and right versions:
+同样（这并不是真的与 `rerere` 有关系），可以使用 `ls-files -u` 来查看冲突文件的之前、左边与右边版本：
 
 [source,console]
 ----
@@ -99,7 +99,7 @@ $ git ls-files -u
 100644 54336ba847c3758ab604876419607e9443848474 3	hello.rb
 ----
 
-Now you can resolve it to just be `puts 'hola mundo'` and you can run the `rerere diff` command again to see what rerere will remember:
+现在可以通过改为 `puts 'hola mundo'` 来解决它，可以再次运行 `rerere diff` 命令来查看 rerere 将会记住的内容：
 
 [source,console]
 ----
@@ -119,9 +119,9 @@ $ git rerere diff
  end
 ----
 
-So that basically says, when Git sees a hunk conflict in a `hello.rb` file that has ``hello mundo'' on one side and ``hola world'' on the other, it will resolve it to ``hola mundo''.
+所以从本质上说，当 Git 看到一个 `hello.rb` 文件的一个块冲突中有 ``hello mundo'' 在一边与 ``hola world'' 在另一边，它会将其解决为 ``hola mundo''。
 
-Now we can mark it as resolved and commit it:
+现在我们可以将它标记为已解决并提交它：
 
 [source,console]
 ----
@@ -131,19 +131,19 @@ Recorded resolution for 'hello.rb'.
 [master 68e16e5] Merge branch 'i18n'
 ----
 
-You can see that it "Recorded resolution for FILE".
+可以看到它 "Recorded resolution for FILE"。
 
 image::images/rerere2.png[]
 
-Now, let's undo that merge and then rebase it on top of our master branch instead. We can move our branch back by using `reset` as we saw in <<_git_reset>>.
+现在，让我们撤消那个合并然后将它变基到 master 分支顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 来回滚分支。
 
 [source,console]
 ----
 $ git reset --hard HEAD^
 HEAD is now at ad63f15 i18n the hello
 ----
 
-Our merge is undone. Now let's rebase the topic branch.
+我们的合并被撤消了。现在让我们变基特性分支。
 
 [source,console]
 ----
@@ -162,7 +162,7 @@ Failed to merge in the changes.
 Patch failed at 0001 i18n one word
 ----
 
-Now, we got the same merge conflict like we expected, but take a look at the `Resolved FILE using previous resolution` line. If we look at the file, we'll see that it's already been resolved, there are no merge conflict markers in it.
+现在，正像我们期望的一样，得到了相同的合并冲突，但是看一下 `Resolved FILE using previous resolution` 这行。如果我们看这个文件，会发现它已经被解决了，而且在它里面没有合并冲突标记。
 
 [source,console]
 ----
@@ -174,7 +174,7 @@ def hello
 end
 ----
 
-Also, `git diff` will show you how it was automatically re-resolved:
+同样，`git diff` 将会显示出它是如何自动地重新解决的：
 
 [source,console]
 ----
@@ -195,7 +195,7 @@ index a440db6,54336ba..0000000
 
 image::images/rerere3.png[]
 
-You can also recreate the conflicted file state with the `checkout` command:
+也可以通过 `checkout` 命令重新恢复到冲突时候的文件状态：
 
 [source,console]
 ----
@@ -212,8 +212,8 @@ def hello
 end
 ----
 
-We saw an example of this in <<_advanced_merging>>.
-For now though, let's re-resolve it by just running `rerere` again:
+我们将会在 <<_advanced_merging>> 中看到这个的一个例子。
+然而现在，让我们通过运行 `rerere` 来重新解决它：
 
 [source,console]
 ----
@@ -227,7 +227,7 @@ def hello
 end
 ----
 
-We have re-resolved the file automatically using the `rerere` cached resolution. You can now add and continue the rebase to complete it.
+我们通过 `rerere` 缓存的解决方案来自动重新解决了文件冲突。现在可以添加并继续变基来完成它。
 
 [source,console]
 ----
@@ -236,4 +236,4 @@ $ git rebase --continue
 Applying: i18n one word
 ----
 
-So, if you do a lot of re-merges, or want to keep a topic branch up to date with your master branch without a ton of merges, or you rebase often, you can turn on `rerere` to help your life out a bit.
+所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，打开 `rerere` 功能可以帮助你的生活变得更美好。