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 がアクティブな場合 (以下の --fork-point の説明を参照)、git log fork_point'..HEAD で表示されるコミットのセットと同じです。または、--root オプションが指定されている場合、git log HEAD で表示されるコミットのセットと同じです。

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

一時領域に以前保存されたコミットは、現在のブランチに一つずつ順番に再適用されます。注: 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> パラメータは、任意の有効なコミット指定子であることに注意してください。

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

競合を手動で解決し、目的の解決策でインデックスを更新した後、git rebase --continue でリベースプロセスを続行できます。

あるいは、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.で修正されたものが、修正する完璧ではないコミットに修正できない場合があります。それはそのコミットがパッチシリーズの奥深くに埋もれているためです。これこそがインタラクティブなリベースの目的です。たくさんの「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」コマンドで識別されたコミットのメッセージは省略されます。ただし、「fixup -c」が使用された場合は除きます。その場合、推奨されるコミットメッセージは「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 を使用してまだコミットされていない変更をスタッシュし、テストを実行し、修正が必要な場合はコミットを修正する必要があります。

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

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

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

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

このリストのCMakeとは関係のないコミットは、CMakeへの切り替えによって導入されたすべてのバグを修正する作業によって動機付けられた可能性が非常に高いですが、それは別の関心事に対応しています。このブランチを2つのトピックブランチに分割するには、ToDoリストを次のように編集できます。

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

git[1]スイートの一部