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`はチェックアウトされたブランチのままになります。

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

結果は次のようになります

rebase --onto を使用して、あるブランチに基づくトピックブランチを別のブランチに移植し、後者のブランチからトピックブランチをフォークしたかのように見せかける方法は次のとおりです。

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

*topic*をブランチ*master*からフォークされたものにする必要があります。たとえば、*topic*が依存する機能が、より安定した*master*ブランチにマージされたためです。ツリーを次のようにしたいと考えています

次のコマンドを使用してこれを実現できます

--ontoオプションのもう1つの例は、ブランチの一部をリベースすることです。次の状況がある場合

コマンド

結果は次のようになります

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

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

コマンド

コミットFとGが削除されます

これは、FとGに何らかの欠陥がある場合、またはtopicAの一部であるべきでない場合に役立ちます。 --onto への引数と <upstream> パラメーターは、有効なコミット風にすることができます。

競合が発生した場合、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-wayマージを使用する戦略（デフォルトの*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 -c" が使用されていない限り、 "fixup" コマンドで識別されるコミットのメッセージは省略されます。その場合、推奨されるコミットメッセージは "fixup -c" コマンドのメッセージのみで、エディターが開き、メッセージを編集できます。"fixup -c" コマンドの内容 (パッチ) は、折りたたまれたコミットに組み込まれます。"fixup -c" コマンドが複数ある場合、最後のコマンドからのメッセージが使用されます。"fixup -c" と同じ動作を得るには、エディターを開かずに "fixup -C" を使用することもできます。

git rebaseは、「pick」が「edit」に置き換えられた場合、またはマージエラーが原因でコマンドが失敗した場合に停止します。編集や競合の解決が完了したら、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に統合されることが予想される場合などです。たとえば、DownloadButtonクラスへの変更によってmasterに発生したマージの競合を解決するためです。

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

通常インタラクティブリベースとは対照的に、pickに加えて、label、reset、およびmergeコマンドがあります。

labelコマンドは、そのコマンドが実行されたときに現在のHEADにラベルを関連付けます。これらのラベルは、リベースの完了時に削除されるワークツリーローカルref（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を明示的に呼び出す場合、ラベルがワークツリーローカルrefであるという事実を利用できます（たとえば、ref refs/rewritten/ontoはラベルontoに対応します）。ジしたいブランチを参照するためです。

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

merge <merge-head> 形式のコマンドを追加することにより、完全に新しいマージコミットを最初から導入することもできます。この形式は、暫定的なコミットメッセージを生成し、常にエディターを開いてユーザーがそれを編集できるようにします。これは、たとえば、トピックブランチが単一の懸念事項以上のものを扱うことが判明し、2つ以上のトピックブランチに分割したい場合に役立ちます。このtodoリストを考えてみましょう。

設定

GIT