SYNOPSIS

git rerere [clear | forget <pathspec>… | diff | status | remaining | gc]

DESCRIPTION

比較的長期間存続するトピックブランチを使用するワークフローでは、開発者は、トピックブランチが完了するまで(「リリース」ブランチにマージされるか、アップストリームに送信されて受け入れられるまで)、同じ競合を何度も解決する必要がある場合があります。

このコマンドは、最初の手動マージにて、自動マージ結果の競合とそれに対応した手動解決結果を記録しておいて、以後の自動マージ結果の競合に、その記録した手動競合解決決定を適用することにより、この処理において開発者を支援します。

Note
 あなたがこのコマンドを有効にするには、構成変数 rerere.enabled を設定する必要があります。

COMMANDS

通常、「git rerere」は、引数やユーザーの介入なしで実行されます。 ただし、動作状態との対話を可能にするいくつかのコマンドがあります。

clear

マージ競合解決決定を中止する場合は、rerereが使用するメタデータをリセットします。 git am [--skip|--abort] または git rebase [--skip|--abort] を呼び出すと、このコマンドが自動的に呼び出されます。

forget <pathspec>

<pathspec> の現在の競合について rerere が記録した競合解決決定をリセットします。

diff

競合解決決定の現在の状態の差分を表示します。これは、ユーザーが競合を解決している間に何が変更されたかを追跡するのに役立ちます。追加の引数は、PATHにインストールされているシステムの「diff」コマンドに直接渡されます。

status

マージ競合解決決定がrerereで記録される競合のあるパスをプリントする。

remaining

rerereによって自動解決されていない競合のあるパスをプリントする。これには、競合するサブモジュールなど、rerereで競合解決決定を追跡できないパスが含まれます。

gc

ずっと前に発生した競合するマージのレコードを剪定(prune)します。デフォルトでは、15日より古い未解決の競合と、60日より古い解決済みの競合は剪定されます。これらのデフォルトは、それぞれ gc.rerereUnresolved および gc.rerereResolved 構成変数を介して制御されます。

DISCUSSION

トピックブランチが分岐してからマスターブランチ(またはアップストリーム)が触れた重複領域をトピックブランチが変更する場合、トピックブランチをアップストリームにプッシュする準備ができる前であっても、最新のマスターでテストすることをお勧めします:

              o---*---o topic
             /
    o---o---o---*---o---o master

このようなテストでは、マスターとトピックを何らかの方法でマージする必要があります。これを行う1つの方法は、マスターをトピックブランチにプルすることです:

        $ git switch topic
        $ git merge master

              o---*---o---+ topic
             /           /
    o---o---o---*---o---o master

* でマークされたコミットは、同じファイルの同じ領域にアクセスします。 + でマークされたコミットを作成するときに競合を解決する必要があります。次に、結果をテストして、進行中の作業が最新のマスターにあるもので引き続き機能することを確認できます。

このテストマージの後、トピックの作業を続行するには2つの方法があります。最も簡単なのは、テストマージコミット + の上に構築することです。トピックブランチでの作業の準備ができたら、トピックブランチをマスターにプルするか、アップストリームにプルするように依頼します。ただし、その時点で、テストマージ + 以降、マスターまたはアップストリームが進んでいる可能性があります。その場合、最終的なコミットグラフは以下のようになります:

        $ git switch topic
        $ git merge master
        $ ... work on both topic and master branches
        $ git switch master
        $ git merge topic

              o---*---o---+---o---o topic
             /           /         \
    o---o---o---*---o---o---o---o---+ master

けれども、トピックブランチの存続期間が長い場合、トピックブランチにはそのような「マスターからのマージ」コミットが多数含まれることになり、開発履歴が不必要に乱雑になります。Linuxカーネルメーリングリストの読者は、サブシステムのメンテナが「役に立たないマージ」でいっぱいのブランチからプルするように要求したときに、Linusがテストマージの頻度が高すぎると不平を言ったことを覚えているかもしれません。

別の方法として、トピックブランチでテストマージをクリーンに保つために、テストマージを吹き飛ばし、テストマージの前に、先端の先に構築し続けることができます:

        $ git switch topic
        $ git merge master
        $ git reset --hard HEAD^ ;# rewind the test merge
        $ ... work on both topic and master branches
        $ git switch master
        $ git merge topic

              o---*---o-------o---o topic
             /                     \
    o---o---o---*---o---o---o---o---+ master

これにより、トピックブランチの準備が整い、マスターブランチにマージされたときに、マージコミットが1つだけ残ります。 このマージでは、 * でマークされたコミットによって導入された競合を解決する必要があります。ただし、この競合は、多くの場合、吹き飛ばしたテストマージを作成したときに解決した競合と同じです。 git rerere は、以前の手動解決からの情報を使用して、この最後の競合するマージを解決するのに役立ちます。

競合する自動マージの直後に「git rerere」コマンドを実行すると、それらの中の、通常の競合マーカー <<<<<<< と ======= と >>>>>>> を使用して、競合する作業ツリーファイルが記録されます。後で、競合の解決が完了した後、「git rerere」を再度実行すると、これらのファイルの解決された状態が記録されます。 masterのトピックブランチへのテストマージを作成したときにこれを行ったとします。

次回、同じ競合する自動マージを確認した後、「git rerere」を実行すると、以前の競合する自動マージ、以前の手動解決、および現在の競合する自動マージの間で3方向のマージが実行されます。この3方向マージが正常に解決される場合、結果は作業ツリーファイルに書き出されるため、手動で解決する必要はありません。注意: git rerere はインデックスファイルをそのままにしておくので、結果に満足のいく場合は、 git diff (または git diff -c)を使用して最終的な健全性チェックを行い、そして、 git add する必要があることに注意してください。

より便利な方法として、「git merge」は、失敗した自動マージで終了すると自動的に「git rerere」を呼び出し、「git rerere」は、新しい競合の場合は手動解決を記録し、そうでない場合は以前の手動解決を再利用します。「git commit」は、マージ結果をコミットするときに「git rerere」も呼び出します。 これが意味することは、（rerere.enabled構成変数を有効にする以外に）自分で特別なことをする必要がないということです。

この例では、テストマージを実行すると、手動の競合解決決定が記録され、記録された競合解決決定が引き続き適用可能である限り、後で更新されたマスターブランチとトピックブランチを使用して実際のマージを実行するときに再利用されます。

「git rerere」レコードの情報は、「git rebase」を実行するときにも使用されます。 テストマージを吹き飛ばし、トピックブランチで開発を続けた後:

              o---*---o-------o---o topic
             /
    o---o---o---*---o---o---o---o   master

        $ git rebase master topic

                                  o---*---o-------o---o topic
                                 /
    o---o---o---*---o---o---o---o   master

git rebase master topic を実行して、トピックをアップストリームに送信する準備ができる前に最新の状態にすることができます。これにより、3方向マージにフォールバックし、前に解決したテストマージと同じように競合します。 「git rerere」は「git rebase」によって実行され、この競合を解決するのに役立ちます。

[注] git rerere は、ファイル内の競合マーカーに依存して競合を検出します。ファイルに競合マーカーのある行と同じように見える行がすでに含まれている場合、「git rerere」は競合解決の記録に失敗する可能性があります。これを回避するには、 gitattributes(5) の conflict-marker-size 設定を使用できます。

GIT

Part of the git(1) suite