From dd128ee1b9141c279c480b2ae390603b584725cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Fri, 3 Jul 2015 15:18:08 +0800 Subject: [PATCH 1/5] Translate 07-git-tools rerere --- book/07-git-tools/sections/rerere.asc | 52 +++++++++++++-------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 6588e17f..1f2e121c 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/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,7 +58,7 @@ $ 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] ---- @@ -66,7 +66,7 @@ $ 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,11 +131,11 @@ 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] ---- @@ -143,7 +143,7 @@ $ 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` 打开帮助你的生活更好一点。 From 1694bc76bbedffc9714c919354b2269d61067501 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Fri, 3 Jul 2015 15:23:52 +0800 Subject: [PATCH 2/5] Translate 07-git-tools rerere v2 --- book/07-git-tools/sections/rerere.asc | 30 +++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 1f2e121c..64f0dbd4 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -3,22 +3,22 @@ `git rerere` 功能是一个隐藏的功能。名字代表 ``reuse recorded resolution'' 并且正如名字所暗示的，它允许你让 Git 记住你如何解决一个块冲突的，这样在下一次看到相同的冲突，Git 可以为你自动地解决它。 -有几种情形下这个功能会非常有用。在文档中提到的一个例子是如果你想要保证一个长期分支会干净地合并，但是又不想要一串中间的合并提交。将 `rerere` 功能打开后偶尔合并，解决冲突，然后返回到合并前。如果你持结这样做，那么最终的合并会很容易，因为 `rerere` 可以为你自动做所有的事情。 +有几种情形下这个功能会非常有用。在文档中提到的一个例子是如果你想要保证一个长期分支会干净地合并，但是又不想要一串中间的合并提交。将 `rerere` 功能打开后偶尔合并，解决冲突，然后返回到合并前。如果你持续这样做，那么最终的合并会很容易，因为 `rerere` 可以为你自动做所有的事情。 同样的策略可以用在如果你想要维持一个变基的分支这样就不用每次解决同样的变基冲突了。或者你将一个分支合并并修复了一堆冲突后想要用变基来替代合并 - 你可能并不想要再次解决相同的冲突。 另一个情形是当你偶尔将一堆正在进化的特性分支合并到一个可测试的头时，就像 Git 项目自身经常做的。如果测试失败，你可以倒回合并之前然后在去除导致测试失败的那个特性分支后重做合并，而不用再次重新解决所有的冲突。 -为了启用 `rerere` 功能，你仅仅需要运行这个配置选项： +为了启用 `rerere` 功能，仅仅需要运行这个配置选项： [source,console] ---- $ git config --global rerere.enabled true ---- -你也通过在特定的仓库中创建 `.git/rr-cache` 目录来开启它，但是设置选项更干净并且可以全局设置。 +也通过在特定的仓库中创建 `.git/rr-cache` 目录来开启它，但是设置选项更干净并且可以全局设置。 -现在我们看一个简单的例子，类似我们之前的那个。假设我们有一个像这样的文件： +现在我们看一个简单的例子，类似之前的那个。假设有一个像这样的文件： [source,console] ---- @@ -29,11 +29,11 @@ def hello end ---- -在一个分支中我们修改单词 ``hello'' 为 ``hola''，然后在另一个分支中我们修改 ``world'' 为 ``mundo''，就像之前一样。 +在一个分支中修改单词 ``hello'' 为 ``hola''，然后在另一个分支中修改 ``world'' 为 ``mundo''，就像之前一样。 image::images/rerere1.png[] -当我们合并两个分支到一起时，我们将会得到一个合并冲突： +当合并两个分支到一起时，我们将会得到一个合并冲突： [source,console] ---- @@ -89,7 +89,7 @@ $ git rerere diff end ---- -同样（这并不是真的与 `rerere` 有关系），你可以使用 `ls-files -u` 来查看冲突文件的之前、左边与右边版本： +同样（这并不是真的与 `rerere` 有关系），可以使用 `ls-files -u` 来查看冲突文件的之前、左边与右边版本： [source,console] ---- @@ -99,7 +99,7 @@ $ git ls-files -u 100644 54336ba847c3758ab604876419607e9443848474 3 hello.rb ---- -现在你可以通过改为 `puts 'hola mundo'` 来解决它，你可以再次运行 `rerere diff` 命令来查看 rerere 将会记住的内容： +现在可以通过改为 `puts 'hola mundo'` 来解决它，可以再次运行 `rerere diff` 命令来查看 rerere 将会记住的内容： [source,console] ---- @@ -131,11 +131,11 @@ Recorded resolution for 'hello.rb'. [master 68e16e5] Merge branch 'i18n' ---- -你可以看到它 "Recorded resolution for FILE"。 +可以看到它 "Recorded resolution for FILE"。 image::images/rerere2.png[] -现在，让我们撤消那个合并然后将它变基到 master 分上顶部来替代它。我们可以通过使用之前在 <<_git_reset>> 看到的 `reset` 将我们的分支移回。 +现在，让我们撤消那个合并然后将它变基到 master 分上顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 将我们的分支移回。 [source,console] ---- @@ -162,7 +162,7 @@ Failed to merge in the changes. Patch failed at 0001 i18n one word ---- -现在，就像我们期望的我们得到了相同的合并冲突，但是看一下 `Resolved FILE using previous resolution` 这行。如果我们看这个文件，我们会发现它已经被解决了，在它里面没有合并冲突标记。 +现在，就像我们期望的我们得到了相同的合并冲突，但是看一下 `Resolved FILE using previous resolution` 这行。如果我们看这个文件，会发现它已经被解决了，在它里面没有合并冲突标记。 [source,console] ---- @@ -174,7 +174,7 @@ def hello end ---- -同样，`git diff` 将会为你显示出它是如何自动地重新解决的： +同样，`git diff` 将会显示出它是如何自动地重新解决的： [source,console] ---- @@ -195,7 +195,7 @@ index a440db6,54336ba..0000000 image::images/rerere3.png[] -你也可以通过 `checkout` 命令重新创建出冲突的文件状态： +也可以通过 `checkout` 命令重新创建出冲突的文件状态： [source,console] ---- @@ -227,7 +227,7 @@ def hello end ---- -我们通过 `rerere` 缓存的解决方案来自动重新解决了文件冲突。你现在可以添加并继续变基来完成它。 +我们通过 `rerere` 缓存的解决方案来自动重新解决了文件冲突。现在可以添加并继续变基来完成它。 [source,console] ---- @@ -236,4 +236,4 @@ $ git rebase --continue Applying: i18n one word ---- -所以，如果你做了很多次重新合并，或者你想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者你经常变基，你可以将 `rerere` 打开帮助你的生活更好一点。 +所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，你可以将 `rerere` 打开帮助你的生活变得更好一点。 From 187fe9fa95dbfc6a6e723a804d4d2dc541cbbf5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Sat, 8 Aug 2015 22:19:44 +0800 Subject: [PATCH 3/5] Review 07-git-tools rerere --- book/07-git-tools/sections/rerere.asc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 64f0dbd4..5ae1da26 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -1,13 +1,13 @@ [[_rerere]] === Rerere -`git rerere` 功能是一个隐藏的功能。名字代表 ``reuse recorded resolution'' 并且正如名字所暗示的，它允许你让 Git 记住你如何解决一个块冲突的，这样在下一次看到相同的冲突，Git 可以为你自动地解决它。 +`git rerere` 功能是一个隐藏的功能。正如它的名字 ``reuse recorded resolution'' 所指，它允许你让 Git 记住解决一个块冲突的方法，这样在下一次看到相同冲突时，Git 可以为你自动地解决它。 有几种情形下这个功能会非常有用。在文档中提到的一个例子是如果你想要保证一个长期分支会干净地合并，但是又不想要一串中间的合并提交。将 `rerere` 功能打开后偶尔合并，解决冲突，然后返回到合并前。如果你持续这样做，那么最终的合并会很容易，因为 `rerere` 可以为你自动做所有的事情。 -同样的策略可以用在如果你想要维持一个变基的分支这样就不用每次解决同样的变基冲突了。或者你将一个分支合并并修复了一堆冲突后想要用变基来替代合并 - 你可能并不想要再次解决相同的冲突。 +可以将同样的策略用在维持一个变基的分支时，这样就不用每次解决同样的变基冲突了。或者你将一个分支合并并修复了一堆冲突后想要用变基来替代合并 - 你可能并不想要再次解决相同的冲突。 -另一个情形是当你偶尔将一堆正在进化的特性分支合并到一个可测试的头时，就像 Git 项目自身经常做的。如果测试失败，你可以倒回合并之前然后在去除导致测试失败的那个特性分支后重做合并，而不用再次重新解决所有的冲突。 +另一个情形是当你偶尔将一堆正在改进的特性分支合并到一个可测试的头时，就像 Git 项目自身经常做的。如果测试失败，你可以倒回合并之前然后在去除导致测试失败的那个特性分支后重做合并，而不用再次重新解决所有的冲突。 为了启用 `rerere` 功能，仅仅需要运行这个配置选项： @@ -16,7 +16,7 @@ $ git config --global rerere.enabled true ---- -也通过在特定的仓库中创建 `.git/rr-cache` 目录来开启它，但是设置选项更干净并且可以全局设置。 +也通过在特定的仓库中创建 `.git/rr-cache` 目录来开启它，但是设置选项更干净并且可以应用到全局。 现在我们看一个简单的例子，类似之前的那个。假设有一个像这样的文件： @@ -44,7 +44,7 @@ Recorded preimage for 'hello.rb' Automatic merge failed; fix conflicts and then commit the result. ---- -你会注意到那个新行 `Recorded preimage for FILE`。除此之外它应该看起来就像一个普通的合并冲突。在这个时候，`rerere` 可以告诉我们几件事。正常地，在这个时候你可以运行 `git status` 来查看所有冲突的内容： +你会注意到那个新行 `Recorded preimage for FILE`。除此之外它应该看起来就像一个普通的合并冲突。在这个时候，`rerere` 可以告诉我们几件事。和往常一样，在这个时候你可以运行 `git status` 来查看所有冲突的内容： [source,console] ---- @@ -135,7 +135,7 @@ Recorded resolution for 'hello.rb'. image::images/rerere2.png[] -现在，让我们撤消那个合并然后将它变基到 master 分上顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 将我们的分支移回。 +现在，让我们撤消那个合并然后将它变基到 master 分上顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 来回滚分支。 [source,console] ---- @@ -236,4 +236,4 @@ $ git rebase --continue Applying: i18n one word ---- -所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，你可以将 `rerere` 打开帮助你的生活变得更好一点。 +所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，打开 `rerere` 可以帮助你的生活变得更美好。 From 2c971cbf650ebad50fec81188da6cb3142e9bd64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Mon, 10 Aug 2015 23:18:29 +0800 Subject: [PATCH 4/5] Review 07-git-tools rerere v2 --- book/07-git-tools/sections/rerere.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 5ae1da26..c1f7aad9 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -135,7 +135,7 @@ Recorded resolution for 'hello.rb'. image::images/rerere2.png[] -现在，让我们撤消那个合并然后将它变基到 master 分上顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 来回滚分支。 +现在，让我们撤消那个合并然后将它变基到 master 分支顶部来替代它。可以通过使用之前在 <<_git_reset>> 看到的 `reset` 来回滚分支。 [source,console] ---- From b8c86d8116a8e3699cbd9f6800f6b0a33cbf9933 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 11 Aug 2015 09:23:19 +0800 Subject: [PATCH 5/5] Review 07-git-tools rerere v3 --- book/07-git-tools/sections/rerere.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index c1f7aad9..a4386f7f 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -162,7 +162,7 @@ Failed to merge in the changes. Patch failed at 0001 i18n one word ---- -现在，就像我们期望的我们得到了相同的合并冲突，但是看一下 `Resolved FILE using previous resolution` 这行。如果我们看这个文件，会发现它已经被解决了，在它里面没有合并冲突标记。 +现在，正像我们期望的一样，得到了相同的合并冲突，但是看一下 `Resolved FILE using previous resolution` 这行。如果我们看这个文件，会发现它已经被解决了，而且在它里面没有合并冲突标记。 [source,console] ---- @@ -195,7 +195,7 @@ index a440db6,54336ba..0000000 image::images/rerere3.png[] -也可以通过 `checkout` 命令重新创建出冲突的文件状态： +也可以通过 `checkout` 命令重新恢复到冲突时候的文件状态： [source,console] ---- @@ -213,7 +213,7 @@ end ---- 我们将会在 <<_advanced_merging>> 中看到这个的一个例子。 -但是现在，让我们只是通过再次运行 `rerere` 来重新解决它： +然而现在，让我们通过运行 `rerere` 来重新解决它： [source,console] ---- @@ -236,4 +236,4 @@ $ git rebase --continue Applying: i18n one word ---- -所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，打开 `rerere` 可以帮助你的生活变得更美好。 +所以，如果做了很多次重新合并，或者想要一个特性分支始终与你的 master 分支保持最新但却不想要一大堆合并，或者经常变基，打开 `rerere` 功能可以帮助你的生活变得更美好。