git-rebase - コミットを別のベースの先端に再適用する

<branch>が指定された場合、git rebaseは他の操作を行う前に自動的にgit switch <branch>を実行します。指定されない場合は、現在のブランチにとどまります。

<upstream>が指定されていない場合、branch.<name>.remoteおよびbranch.<name>.mergeオプションで設定されたアップストリームが使用され（詳細はgit-config[1]を参照）、--fork-pointオプションが仮定されます。現在どのブランチにもいない場合、または現在のブランチに設定されたアップストリームがない場合、リベースは中断されます。

現在のブランチで行われたコミットのうち、<upstream>にはない変更はすべて一時領域に保存されます。これは、git log <upstream>..HEADによって表示されるのと同じコミットの集合です。あるいは、--fork-pointが有効な場合はgit log 'fork_point'..HEAD（--fork-pointに関する記述を以下参照）、--rootオプションが指定されている場合はgit log HEADによって表示されるコミットの集合です。

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

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

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

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

この時点から、以下のいずれかのコマンドの結果は

次のようになります。

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

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

次のようになります。

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を次で元に戻すこともできます。

このセクションのオプションは、互いを含め、他のオプションと併用することはできません。

以下のオプション

は以下のオプションと非互換です。

さらに、以下のオプションの組み合わせは非互換です。

git rebaseには、applyとmergeの2つの主要なバックエンドがあります。（applyバックエンドは以前はamバックエンドとして知られていましたが、動詞のように見えて名詞ではないため混乱を招きました。また、mergeバックエンドは以前はインタラクティブバックエンドとして知られていましたが、現在では非インタラクティブなケースでも使用されます。どちらもそれぞれの基盤となる低レベル機能に基づいて改名されました。）これら2つのバックエンドの動作にはいくつかの微妙な違いがあります。

マージ機構（git mergeおよびgit pullコマンド）は、バックエンドのマージ戦略を-sオプションで選択できます。一部の戦略は独自のオプションも持つことができ、これらはgit mergeやgit pullに-X<option>引数を与えることで渡すことができます。

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

共有しているリポジトリでgit rebaseを使用することの意味を理解しておく必要があります。以下の「アップストリームのリベースからの復旧」も参照してください。

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

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

対話的にリベースするとは、リベースされるコミットを編集する機会があることを意味します。コミットの順序を変更したり、それらを削除したり（不正なパッチや不要なパッチを取り除く）、することができます。

対話モードは、次のようなワークフローを意図しています。

ここで、2.はいくつかのインスタンスで構成されます。

a) 通常の使用

b) 独立したフィックスアップ

b.2.で修正されたものが、それが修正する完璧ではないコミットに修正（amend）できないことがあります。なぜなら、そのコミットがパッチシリーズの深く埋もれているからです。対話型リベースはまさにそのためにあります。「a」や「b」をたくさん行った後、コミットを並べ替えたり編集したり、複数のコミットを1つにスカッシュしたりするために使用します。

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

指定されたコミット以降の現在のブランチのすべてのコミット（マージコミットは無視されます）がエディタで開かれます。このリストのコミットは自由に並べ替えたり、削除したりできます。リストはほぼ次のようになります。

一行の説明は純粋にあなたの便宜のためのものです。git rebaseはこれらを見ずにコミット名（この例では「deadbee」と「fa1afe1」）を見るので、名前を削除したり編集したりしないでください。

コマンド「pick」を「edit」に置き換えることで、そのコミットを適用した後にgit rebaseを停止させることができます。これにより、ファイルを編集したり、コミットメッセージを編集したり、コミットを修正したり、リベースを続行したりすることができます。

リベースを中断するには（「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」を使用することもできます。

「pick」が「edit」に置き換えられた場合、またはマージエラーによりコマンドが失敗した場合、git rebaseは停止します。編集および/またはコンフリクトの解決が完了したら、git rebase --continueで続行できます。

例えば、最後の5つのコミットを並べ替えて、HEAD~4だったものを新しいHEADにしたい場合。それを実現するには、git rebaseを次のように呼び出します。

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

マージコミットを再作成したい場合があります。例えば、次のような履歴がある場合です。

"A"から始まるサイドブランチを"Q"にリベースしたいとします。現在のHEADが"B"であることを確認し、次を呼び出します。

コミットの並べ替えや編集は、通常、テストされていない中間ステップを作成します。履歴の編集が何も壊していないか、テストを実行するか、または少なくとも履歴の中間点で「exec」コマンド（ショートカット「x」）を使用して再コンパイルすることで確認したい場合があります。これは、次のようなTODOリストを作成することで実行できます。

対話型リベースは、コマンドが失敗した場合（つまり、0以外のステータスで終了した場合）に停止し、問題を修正する機会を提供します。git rebase --continueで続行できます。

「exec」コマンドはシェル（デフォルトは通常/bin/sh）でコマンドを起動するため、シェル機能（「cd」、「>」、「;」など）を使用できます。コマンドは作業ツリーのルートから実行されます。

このコマンドを使用すると、中間コミットがコンパイル可能であることを確認できます。TODOリストは次のようになります。

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

中間リビジョンが一貫していること（コンパイルできるか、テストスイートに合格するかなど）を完全に確信できない場合は、各コミット後にgit stashを使用して未コミットの変更をスタッシュし、テストを行い、修正が必要な場合はコミットをamendするべきです。

他の人が作業のベースにしているブランチをリベースする（またはその他の書き換え形式）のは悪いアイデアです。そのブランチの下流にいる人は全員、手動で履歴を修正せざるを得なくなります。このセクションでは、下流側の視点から修正を行う方法を説明します。しかし、本当の解決策は、そもそもアップストリームをリベースしないことです。

例として、誰かが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コマンドは通常の merges にはortマージ戦略を、octopus merges にはoctopusを使用します。リベースを呼び出す際に--strategy引数を使用してすべての merges のデフォルト戦略を指定することも、execコマンドを使用してgit mergeを--strategy引数付きで明示的に呼び出すことで、対話型コマンドリスト内の特定の merges を上書きすることもできます。このようにgit mergeを明示的に呼び出す際、ラベルが作業ツリーローカルな参照であるという事実（例えば、参照refs/rewritten/ontoはラベルontoに対応します）を利用して、マージしたいブランチを参照できることに注意してください。

注記: 最初のコマンド（label onto）は、コミットがリベースされるリビジョンにラベルを付けます。名前ontoは、--ontoオプションへの言及として、単なる慣例です。

また、merge <merge-head>の形式のコマンドを追加することで、完全に新しいマージコミットをゼロから導入することも可能です。この形式は仮のコミットメッセージを生成し、常にエディタを開いてユーザーが編集できるようにします。これは、例えばトピックブランチが単一の関心事だけでなく複数の関心事を扱うことになり、2つ以上のトピックブランチに分割したい場合などに役立ちます。このTODOリストを検討してください。

このリストにあるCMakeに関連しない1つのコミットは、CMakeへの切り替えによって導入されたすべてのバグを修正する作業によって動機付けられたのかもしれませんが、それは別の懸念事項に対処しています。このブランチを2つのトピックブランチに分割するには、TODOリストを次のように編集できます。

このセクションのこの行より下のすべての内容は、git-config[1]のドキュメントから選択的に含まれています。内容はそちらで見られるものと同じです。

git[1] スイートの一部