git-rebase(1) Manual Page

<branch> が指定されている場合、 「git rebase」は他の処理を行う前に自動で git switch <branch> を実行します。それ以外の場合は、引き続き現在のブランチに滞在しています。

<upstream> が指定されていない場合、 branch.<name>.remote と branch.<name>.mergebranch オプションで構成されたアップストリーム(詳細はgit-config(1) 参照) および --fork-point オプションが想定されています。あなたが現在ブランチを一切使用していない場合、または、現在のブランチにアップストリームが構成されていない場合、リベースは中止(abort)されます。

現在のブランチでコミットによって行われたが、 <upstream> に無いすべての変更は、一時領域(temporary area)に保存されます。 これは git log <upstream>..HEAD で表示されるのと同じコミットのセットで、または --fork-point がアクティブな場合 git log 'fork_point'..HEAD で表示されるのと同じコミットのセットで、または --root オプションが指定されている場合 git log HEAD で表示されるのと同じコミットのセットです。

現在のブランチは <upstream> にリセットされます。 または --onto オプションが指定されている場合は <newbase> にリセットされます。 これは、 git reset --hard <upstream> (または <newbase> )とまったく同じ効果があります。 ORIG_HEAD は、リセット前にブランチの先端を指すように設定されています。

以前に一時領域に保存されたコミットは、現在のブランチに1つずつ順番に再適用されます。注意: HEAD..<upstream> でのコミットと同一のテキスト変更を導入する HEAD でのコミットは省略されることに注意してください(つまり、異なるコミットメッセージまたはタイムスタンプで、アップストリームで既に受け入れ済のパッチはスキップされます)。

マージに失敗すると、このプロセスが完全には自動で行われなくなる事があります。あなたは、このようなマージの失敗を解決し、そして git rebase --continue を実行する必要があります。 別のオプションとしては、 git rebase --skip でマージの失敗を引き起こしたコミットをバイパスすることです。そして、元の <branch> をチェックアウトし、.git/rebase-apply 作業ファイルを削除するには、代わりにコマンド git rebase --abort を使用します。

以下の履歴が存在し、現在のブランチが topic であるとします:

この時点で、以下のコマンドのいずれかを実行します:

そうすると以下のようになります:

注意 : 後者の形式は、 git checkout topic の後に git rebase master が続く省略形です。 リベースが終了すると、チェックアウトされたブランチ(topic)のままになります。

(たとえば、アップストリームに適用されたパッチをメールで送信したため)アップストリームブランチにすでに行った変更が含まれている場合、そのコミットはスキップされ、警告が発行されます(merge バックエンドが使用されている場合)。たとえば、以下の履歴で git rebase master を実行します(A' と A は同じ変更セットを導入しますが、コミッター情報は異なります):

これの結果は以下のようになります:

これは、あるブランチに基づいてトピックブランチを別のブランチに移植し、 rebase --onto を使用して、トピックブランチを後者のブランチからフォークしたふりをする方法です。

まず、「topic」がブランチ「next」に基づいているとしましょう。 たとえば「topic」で開発された機能は、「next」にあるいくつかの機能に依存しています。

我々は topic をブランチ master からフォークさせたいのです。たとえば「topic」が依存する機能が、より安定した「master」ブランチにマージされたためです。 ツリーを以下のようにしたいわけです:

これは、以下のコマンドを使用して取得できます:

--onto オプションの別の例は、ブランチの一部をリベースすることです。 以下のような状況の場合:

そして、以下のコマンドを実行します

そうすると結果は以下のようになります:

これは、topicBがtopicAに依存していない場合に役立ちます。

コミットの範囲は、リベースで削除することもできます。以下の状況の場合:

そして、以下のコマンドを実行します

上記を実行すると、以下のようにコミットFとGが削除されます:

これは、 F と G に何らかの欠陥がある場合、または、topicA の一部であってはならない場合に役立ちます。注意: --onto と <upstream> パラメーターの引数は、任意の有効なコミットっぽい何か(commit-ish)にすることができることに注意してください。

競合が発生した場合、 git rebase は最初の問題のあるコミットで停止し、ツリーに競合マーカーを残します。 あなたは git diff を使用して、マーカー(<<<<<<)を見つけ、編集して競合を解決できます。編集するファイルごとに、競合が解決されたことをGitに通知する必要があります。通常、これは以下の方法で行います

競合を手動で解決し、あなたが望んだ解決策でインデックスを更新した後、以下のコマンドでリベースプロセスを続行できます

あるいは、以下のように git rebase を元に戻す(undo)こともできます

このセクションの各オプションは、このセクションのオプションを組み合わせる事も含めて、他のオプションと一緒に使うことはできません。

これらのオプション:

は、以下のオプションと互換性がありません:

さらに、以下のオプションの組み合わせには互換性がありません:

git rebaseには、 apply と merge の2つの主要バックエンドがあります。 (apply バックエンドは以前は am バックエンド と呼ばれていましたが、名詞ではなく動詞のように見えるため混乱を招きました。また、 merge バックエンドは以前は interactive バックエンドと呼ばれていましたが、現在は 非対話型の場合にも使用されます。どちらも、それぞれを支える低レベルの機能に基づいて名前が変更されました。）これら2つのバックエンドの振る舞いには微妙な違いがあります:

マージ機構(git merge と git pull コマンド)では、バックエンドの「マージ戦略」を -s オプションで選択することができます。 いくつかの戦略では、独自のオプションを指定することができます。これは、 git merge や git pull に -X<option> 引数として渡すことができます。

3方向マージ(デフォルトの「ort」を含む)を使用する戦略では、両方のブランチで変更が行われたが、後で一方のブランチで元に戻された場合、その変更はマージされた結果に表示されます。一部の人々は、この振る舞いを混乱させると感じています。これは、個々のコミットではなく、ヘッドとマージベースのみがマージの実行時に考慮されるために発生します。したがって、マージアルゴリズムは、元に戻された変更をまったく変更なしと見なし、代わりに変更されたバージョンに置き換えます。

あなたは共有リポジトリで git rebase を使用することの意味を理解する必要があります。下記「RECOVERING FROM UPSTREAM REBASE」も参照してください。

リベースを実行すると、最初にpre-rebaseフックが存在する場合はそれが実行されます。このフックを使用して、健全性チェックを実行し、適切でない場合はリベースを拒否できます。例については、テンプレートの pre-rebase hook スクリプトを参照してください。

完了すると、<branch>が現在のブランチになります。

対話的にリベースするということは、あなたがリベースされるコミットを編集する機会があることを意味します。コミットを並べ替えたり、削除したりできます(不良パッチやその他の不要なパッチを削除します)。

対話モードは、以下のタイプの作業フローを対象としています:

ここで、 (2) は以下のいくつかの作業で構成されています

a) 普段

b) 独立した修正

bの(2) で修正したコミットがパッチシリーズの中に深く埋もれているために、完全ではないコミットに戻せない(amend)ことがあります。これこそが対話型リベースの目的です。たくさんの "a" と "b" の後に、コミットを並べ替えたり編集したり、複数のコミットをひとつにまとめたりするために使用します。

そのまま保持したい最後のコミットから開始します:

エディターは、あなたの現在のブランチのすべてのコミット(マージコミットは無視)で起動されます。これは、指定のコミットの後に発生します。あなたは、このリストのコミットを心ゆくまで並べ替えたり、削除したりできます。そして、リストは多かれ少なかれ以下のようになります:

1行説明は、純粋にあなたの備忘のためです。 git rebase はそれらを参照せず、コミット名（この例では "deadbee" と "fa1afe1" ）を参照するため、名前を削除または編集しないでください。

コマンド「pick」をコマンド「edit」に置き換えることで、 git rebase にそのコミットを適用した後に停止(stop)するように指示できます。これにより、あなたはファイルやコミットメッセージを編集し、コミットを修正(amend)して、リベースを続行できます。

リベースを中断するには(edit コマンドと同様、ただし最初にコミットを選択せずに)、 break コマンドを使用します。

あなたがコミットのコミットメッセージを編集したいだけの場合は、コマンド pick をコマンド reword に置き換えます。

コミットを削除するには、コマンド pick を drop に置き換えるか、あるいはマッチする行を削除します。

2つ以上のコミットを1つにまとめる場合は、2番目以降のコミットのコマンド pick を squash または fixup に置き換えます。コミットに異なる作者がいた場合、折りたたまれたコミットは最初のコミットの作者に帰属します。折りたたまれたコミットに対して推奨されるコミットメッセージは、最初のコミットのメッセージと squash コマンドで識別されるメッセージを連結したもので、 fixup -c が使用されていない限り、fixupコマンドで識別されるコミットのメッセージは省略されます。fixup -c が使用された場合、提案されたコミットメッセージは fixup -c コミットのメッセージのみであり、エディタが開いてメッセージを編集できます。 fixup -c コミットの内容(パッチ)は、折りたたまれたコミットに引き続き組み込まれます。 fixup -c コミットが複数ある場合は、最後のコミットからのメッセージが使用されます。あなたは fixup -C を使用して、エディターを開かないことを除いて fixup -c と同じ動作をさせることもできます。

「git rebase」は、 pick が edit に置き換えられたとき、またはマージエラーのためにコマンドが失敗したときに停止(stop)します。 競合の編集や解決が完了したら、 あなたは git rebase --continue で続行できます。

たとえば、最後の5つのコミットを並べ替えて、 HEAD~4 であったものが新しいHEADになるようにします。これを実現するには、以下のように「git rebase」を呼び出します:

そして、最初のパッチをリストの最後に移動します。

たとえば、あなたが以下のような履歴を持っているなら、マージコミットを再作成することをお勧めします:

あなたは A から Q までのブランチをリベースしたいとします。現在のHEADが B であることを確認して、以下を実行します

コミットの並べ替えと編集は通常、テストされていない中間ステップを作成します。テストを実行するか、少なくとも「exec」コマンド(ショートカット「x」)を使用して履歴の中間ポイントで再コンパイルすることにより、履歴の編集で何も壊れていないことを確認することをお勧めします。これを行うには、以下のようなToDoリストを作成します:

コマンドが失敗すると（つまり、0以外のステータスで終了すると）、対話的リベースが停止(stop)し、あなたには問題を修正する機会が与えられます。あなたは git rebase --continue で続行できます。

「exec」コマンドは、シェル($SHELL で指定されたもの、または $SHELL が設定されていない場合はデフォルトのシェル)でコマンドを起動するため、シェル機能("cd"、">"、";" など)を使用できます。コマンドは、作業ツリーのルートから実行されます。

このコマンドを使用すると、あなたは中間コミット(intermediate commits)がコンパイル可能であることを確認できます。ToDoリストは以下のようになります:

対話モードでは、アクション「edit」でコミットをマークできます。 ただし、これは必ずしも「git rebase」がこの編集の結果が正確に1つのコミットであることを期待していることを意味するわけではありません。 実際、あなたはコミットを元に戻す(undo)ことも、他のコミットを追加することもできます。そしてこれは、コミットを2つに分割するために使用できます:

あなたが中間リビジョンの一貫性(コンパイル、テストスイートの合格など)が完全には分からない場合は、「git stash」を使用して、各コミット後にまだコミットされていない変更を隠し、修正が必要な場合はコミットをテストして修正する必要があります。

他の人がベースにしているブランチをリベースする (あるいは他の形で書き換える) のは悪い考えです。そのブランチの下流の人は、自分の履歴を手動で修正することを余儀なくされます。 このセクションでは、下流側の視点から見た修正の方法を説明します。 しかし、本当の意味での修正は、そもそも上流のリベースを行わないことです。

説明のために、誰かが「subsystem」ブランチを開発し、この「subsystem」に依存する「topic」に取り組んでいる状況にあると仮定します。たぶん以下のような履歴です:

subsystem が master に対してリベースされる場合、以下が発生します:

これで、あなたは通常どおり開発を続行し、最終的に topic を subsystem にマージすると、 以下のように、 subsystem からのコミットは永久に複製されたままになります:

このような重複は、履歴が乱雑になり、追跡が困難になるため、一般的に眉をひそめられる行為です。これをクリーンアップするには、「topic」のコミットを新しい「subsystem」の先端に移植する必要があります。つまり、「topic」をリベースする必要があります。これは影響が波及します。「topic」の下流にいる人もリベースを余儀なくされます！

2種類の修正パターン(簡単な場合と難しい場合)があります。以下のサブセクションで議論します:

対話的リベースコマンドは、元々、個々のパッチシリーズを処理するために設計されました。そのため、開発者がブランチの作業中にその時点で最新の「master」をマージした可能性があり、最終的にすべてのコミットを「master」にリベースする(マージコミットをスキップする)ため、マージコミットをtodoリストから除外することは理にかなっています。

ただし、開発者がマージコミットを再作成する正当な理由があります。それは複数の相互に関連するブランチで作業するときに、ブランチ構造(または「コミットトポロジ」）を維持するためです。

次の例では、開発者はボタンの定義方法をリファクタリングするトピックブランチと、そのリファクタリングを使用して[バグの報告]ボタンを実装する別のトピックブランチで作業します。 git log --graph --format=%s -5 の出力は以下のようになります:

開発者は、ブランチトポロジを維持しながら、これらのコミットを新しい master にリベースしたい場合があります。たとえば、最初のトピックブランチが2番目のブランチよりもはるかに早く master に統合されると予想される場合、たとえば、マージの競合を解決して、 master にしたDownloadButtonクラスへの変更を解決します。

このリベースは、 --rebase-merges オプションを使用して実行できます。 以下のようなToDoリストが生成されます:

通常の対話的リベースとは対照的に、 pick コマンドに加えて label と reset と`merge` コマンドがあります。

label コマンドは、そのコマンドが実行されるときに、ラベルを現在のHEADに関連付けます。これらのラベルは、ワークツリーローカル参照(refs/rewritten/<label>)として作成され、リベースが終了すると削除されます。こうすれば、同じリポジトリにリンクされている複数のワークツリーでのリベース操作が相互に干渉することはありません。 label コマンドが失敗した場合、すぐに再スケジュールされ、続行する方法について役立つメッセージが表示されます。

reset コマンドは、HEADとインデックスとワークツリーを指定されたリビジョンにリセットします。 これは exec git reset --hard <label> に似ていますが、追跡していないファイルの上書きを拒否します。 reset コマンドが失敗すると、すぐに再スケジュールされ、todoリストを編集する方法がわかりやすく表示されます(これは通常、 reset コマンドがtodoリストに手動で挿入され、タイプミスが含まれている場合に発生します)。

merge コマンドは、指定されたリビジョンをその時点でHEADであるものにマージします。 -C <original-commit>`を使用すると、指定されたマージコミットのコミットメッセージが使用されます。 `-C が小文字の -c に変更されると、ユーザーがメッセージを編集できるように、マージが成功した後にメッセージがエディターで開かれます。

マージの競合以外の理由で merge コマンドが失敗した場合(つまり、マージ操作が開始されなかった場合)、コマンドは直ちに再スケジュールされます。

デフォルトでは、「merge」コマンドは通常のマージには「ort」マージ戦略を使用し、タコマージ(octopus merges)には「octopus」マージ戦略を使用します。リベースを呼び出すときに --strategy 引数を使用して、すべてのマージのデフォルト戦略を指定できます。または、 exec コマンドを使用して明示的に --strategy 引数を伴った git merge を呼び出すことにより、コマンドの対話リスト内の特定のマージをオーバーライドできます。注意:このように明示的に git merge を呼び出す場合、マージするブランチを参照するために、ラベルがワークツリーローカル参照であるという事実(たとえば、 ref refs/rewritten/onto はラベル onto に対応します)を利用できることに注意してください。

注意: 最初のコマンド(label onto)は、コミットがリベースされるリビジョンにラベルを付けます。 onto`という名前は単なる慣例で、 `--onto オプションにちなんでいます。

merge <merge-head> の形式のコマンドを追加することにより、完全に新しいマージコミットを最初から導入することもできます。この形式は、暫定的なコミットメッセージを生成し、常にエディターを開いてユーザーが編集できるようにします。これは便利です。例えば、トピックブランチが複数の懸念事項に対処していることが判明し、2つ以上のトピックブランチに分割したい場合です。以下のToDoリストを検討してみてください:

CMakeに関連しないこのリストの1つのコミットは、CMakeに切り替えることによって発生したすべてのバグの修正に取り組むことによって動機付けられた可能性がありますが、しかし、それは別の懸念に対処します。このブランチを2つのトピックブランチに分割するには、ToDoリストを以下のように編集できます:

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は git-config(1) ドキュメント にあるものと同一です:

Part of the git(1) suite