You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You also don’t need to be in interactive add mode to do the partial-file staging – you can start the same script by using `git add -p` or `git add --patch` on the command line.
Furthermore, you can use patch mode for partially resetting files with the `reset --patch` command, for checking out parts of files with the `checkout --patch` command and for stashing parts of files with the `stash save --patch` command. We'll go into more details on each of these as we get to more advanced usages of these commands.
Copy file name to clipboardExpand all lines: book/07-git-tools/sections/rerere.asc
+75Lines changed: 75 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,24 +1,45 @@
1
1
[[_rerere]]
2
2
=== Rerere
3
3
4
+
//////////////////////////
4
5
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.
6
+
//////////////////////////
7
+
`git rerere` コマンドはベールに包まれた機能といってもいいでしょう。これは ``reuse recorded resolution'' の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。
5
8
9
+
//////////////////////////
6
10
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.
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.
21
+
//////////////////////////
22
+
その他にも、開発中のトピックブランチをいくつもまとめてマージして、テスト可能な HEAD を生成するとき（Git 本体のプロジェクトでよく行われています）にもこのコマンドが使えます。テストが失敗したら、マージを取り消したうえで失敗の原因となったブランチを除外してからテストを再実行するわけですが、`rerere` を使えばその際にコンフリクトを解消する必要がなくなるのです。
11
23
24
+
//////////////////////////
12
25
To enable the `rerere` functionality, you simply have to run this config setting:
26
+
//////////////////////////
27
+
`rerere` を有効にするには、以下の設定コマンドを実行しましょう。
13
28
14
29
[source,console]
15
30
----
16
31
$ git config --global rerere.enabled true
17
32
----
18
33
34
+
//////////////////////////
19
35
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.
When we merge the two branches together, we'll get a merge conflict:
62
+
//////////////////////////
63
+
これら2つのブランチをマージしようとすると、コンフリクトが発生します。
37
64
38
65
[source,console]
39
66
----
@@ -44,7 +71,10 @@ Recorded preimage for 'hello.rb'
44
71
Automatic merge failed; fix conflicts and then commit the result.
45
72
----
46
73
74
+
//////////////////////////
47
75
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:
76
+
//////////////////////////
77
+
コマンド出力に `Recorded preimage for FILE` という見慣れない行があるのに気づかれたでしょう。他の部分は、よくあるコンフリクトのメッセージと変わりありません。この時点で、`rerere` からわかることがいくつかあります。こういった場合、いつもであれば以下のように `git status` を実行し、何がコンフリクトしているのかを確認するものです。
48
78
49
79
[source,console]
50
80
----
@@ -58,15 +88,21 @@ $ git status
58
88
#
59
89
----
60
90
91
+
//////////////////////////
61
92
However, `git rerere` will also tell you what it has recorded the pre-merge state for with `git rerere status`:
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''.
@@ -131,19 +179,28 @@ Recorded resolution for 'hello.rb'.
131
179
[master 68e16e5] Merge branch 'i18n'
132
180
----
133
181
182
+
//////////////////////////
134
183
You can see that it "Recorded resolution for FILE".
184
+
//////////////////////////
185
+
コマンド出力から、Git が "Recorded resolution for FILE"、FILE のコンフリクト解消方法を記録したようです。
135
186
136
187
image::images/rerere2.png[]
137
188
189
+
//////////////////////////
138
190
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>>.
Our merge is undone. Now let's rebase the topic branch.
202
+
//////////////////////////
203
+
マージが取り消されました。続いてトピックブランチをリベースしてみます。
147
204
148
205
[source,console]
149
206
----
@@ -162,7 +219,10 @@ Failed to merge in the changes.
162
219
Patch failed at 0001 i18n one word
163
220
----
164
221
222
+
//////////////////////////
165
223
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.
224
+
//////////////////////////
225
+
予想どおり、マージコンフリクトが発生しました。一方、`Resolved FILE using previous resolution` というメッセージも出力されています。該当のファイルを確認してみてください。コンフリクトはすでに解消されていて、コンフリクトを示すマーカーは挿入されていないはずです。
166
226
167
227
[source,console]
168
228
----
@@ -174,7 +234,10 @@ def hello
174
234
end
175
235
----
176
236
237
+
//////////////////////////
177
238
Also, `git diff` will show you how it was automatically re-resolved:
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.
0 commit comments