Git rebase onto とは？基本から理解する使い方

By /

Git rebase –onto とは？基本から理解する詳細な使い方

はじめに：Gitにおける変更履歴の管理とrebaseの役割

Gitを使った開発において、複数の変更を同時に進めるためにブランチは不可欠な機能です。そして、ブランチ間の変更を取り込んだり、変更履歴を整理したりするために、git mergeとgit rebaseという2つの主要なコマンドが使われます。

git mergeは、指定したブランチの変更を現在のブランチに取り込み、マージコミットを作成することで変更履歴を統合します。これは履歴をそのまま保持するため、追跡が容易であるというメリットがありますが、ブランチの分岐やマージのたびにマージコミットが増え、履歴が複雑になりがちです。

一方、git rebaseは、「付け替え」という意味の通り、現在のブランチのコミットを別のブランチ（または特定のコミット）の先端に移動させることで、変更履歴を直線的に保つコマンドです。これにより、ブランチの履歴がシンプルになり、後から追跡しやすくなるというメリットがあります。特に、featureブランチでの開発をmainブランチの最新状態に合わせて整理したい場合などに有効です。

git rebaseの基本的な使い方は、git rebase <base_branch>のように、現在のブランチのコミットを<base_branch>の先端に移動させるというものです。しかし、Gitのブランチ運用やプロジェクトの履歴は常にシンプルとは限りません。特定のコミット範囲だけを移動したい、あるいは現在のブランチではなく、全く別のコミットツリーの上にコミット群を移動させたい、といったより複雑なニーズが出てくることがあります。

このような場合に真価を発揮するのが、今回詳細に解説するgit rebase --ontoコマンドです。--ontoオプションを使用することで、どのコミットを新しいベースにするか、どのコミット範囲を移動させるかを、より柔軟かつ細かく指定できるようになります。

この記事では、まずgit rebaseの基本を簡単に復習し、その上でgit rebase --ontoが必要となる背景、基本的な構文と各引数の意味、そして様々な具体的な使用例を通して、その強力な機能を深く理解することを目指します。また、履歴を変更するコマンドであるため、使用上の注意点や、万が一の場合の対処法についても詳しく解説します。

Git rebaseの基本（復習）

git rebase <base>コマンドは、現在のブランチ（HEAD）のコミットを、指定した<base>ブランチ（またはコミット）の先端に「付け替える」ためのコマンドです。

例として、以下のようなコミット履歴を考えます。

A -- B -- C (main)
\
D -- E -- F (feature)

ここで、featureブランチにいる状態でgit rebase mainを実行すると、以下のようになります。

  1. Gitは、featureブランチの分岐点（mainブランチの先端であるコミットCの一つ前の共通の祖先、この場合はコミットB）を見つけます。
  2. featureブランチ固有のコミット（D, E, F）を一時的な領域に保存します。
  3. 現在のブランチ（feature）のHEADを、指定した<base>ブランチ（main）の先端（コミットC）に移動させます。
  4. 一時保存しておいたコミットを、新しいHEAD（コミットC）の上に順番に再適用（リプレイ）します。

このプロセスを経て、履歴は以下のようになります。

A -- B -- C (main)
\
D' -- E' -- F' (feature)

ここで、D', E', F'は元のD, E, Fと同じ内容ですが、親コミットが変わったため、異なる新しいコミットIDを持つことになります。これが「コミットの付け替え」です。

rebaseのメリット:

  • 履歴が直線的になり、追いやすくなります。
  • マージコミットが生成されないため、コミットグラフがシンプルになります。
  • featureブランチをmainブランチの最新状態に合わせて整理し、その後のmergeをfast-forward mergeにできる可能性があります。

rebaseのデメリット:

  • コミットIDが変わる: 上記のように、rebaseされたコミットは新しいIDを持ちます。これは、特に共有リモートリポジトリで公開済みのコミットに対してrebaseを行うと、他の開発者の履歴と食い違いを生じさせ、混乱の原因となる可能性があります。リモートにpush済みの共有ブランチに対してrebaseを行うべきではないと言われる最大の理由です。
  • コンフリクト解決の手間: 複数のコミットを再適用する際に、各コミットでコンフリクトが発生する可能性があります。その都度解決が必要になります。

基本的なgit rebase <base>の動作は、「現在のブランチの、<base>ブランチとの共通の祖先よりも新しい全てのコミットを、<base>の先端に移動する」というものです。この「共通の祖先よりも新しい全てのコミット」というルールが、後述する--ontoがどのように役立つかに関わってきます。

git rebase --ontoの登場：なぜ通常のrebaseでは不十分な場合があるのか？

通常のgit rebase <base>は、「現在のブランチ」と「<base>」という2つの参照（ブランチやコミット）間の関係に基づいて、移動対象のコミット範囲と移動先を決定します。移動対象は「現在のブランチのHEADまでのコミットのうち、<base>との共通の祖先よりも新しいもの」という固定的なルールで決まります。移動先は常に<base>の先端です。

しかし、以下のようなシナリオでは、この固定的なルールでは対応できません。

  1. 特定のコミット範囲だけを移動したい: ブランチ全体ではなく、そのブランチに含まれる特定の連続したコミット群だけを移動したい場合があります。例えば、一つのブランチで複数の独立した機能の開発を進めてしまい、それらを後から別々のブランチに分割したい、といった状況です。通常のrebase <base>では、共通の祖先からHEADまでの全てのコミットが対象となってしまいます。
  2. 移動先のベースを特定のコミットにしたい: 通常のrebase <base>では、移動先は常に<base>ブランチの最新コミットになります。しかし、特定のタグや、過去の特定のコミットの上にコミット群を移動させたい場合があります。
  3. ブランチが複雑な構造になっている: 複数のブランチが頻繁にマージされたり、cherry-pickされたりして、履歴が複雑になっている場合、共通の祖先からの範囲指定だけでは意図したコミット群を正確に選択できないことがあります。

これらの課題を解決し、より柔軟にコミットの付け替えを行うために導入されたのが、git rebase --ontoオプションです。

git rebase --ontoの基本的な構文

git rebase --ontoコマンドの基本的な構文は以下の通りです。

bash
git rebase --onto <new_base> <upstream_base> <topic_branch>

このコマンドは、<topic_branch>に含まれるコミットのうち、<upstream_base>コミットよりも新しいコミット群を、<new_base>コミット（またはブランチ）の直後に移動させます。

各引数の意味を詳しく見ていきましょう。

  • <new_base>:

    • これは、新しいベースとなるコミットまたはブランチを指定します。
    • 移動対象のコミット群は、この<new_base>が指すコミットの直後に付け替えられます。
    • 例えば、mainブランチの最新状態の上にコミットを移動させたい場合は、ここにmainと指定します。特定のコミットIDの上に移動させたい場合は、そのコミットIDを指定します。

  • <upstream_base>:

    • これは、移動対象のコミット範囲を指定する境界となるコミットです。
    • Gitは、<topic_branch>のHEADまでのコミット履歴を遡り、この<upstream_base>コミットを見つけます。
    • そして、<topic_branch>の履歴のうち、<upstream_base>よりも（ブランチの先端側にある）新しい全てのコミットを移動対象とします。
    • 言い換えると、<upstream_base>..<topic_branch> の範囲に含まれるコミットが移動対象となります。（ただし、<upstream_base>自体は含まれません）
    • これは、通常のgit rebase <base>で自動的に計算される「共通の祖先」を手動で指定するようなものです。ただし、必ずしも共通の祖先である必要はなく、単なる範囲指定の始点として機能します。
    • この引数は省略可能です。省略した場合、通常のgit rebase <new_base>と同様に、現在のブランチと<new_base>の共通の祖先が自動的に<upstream_base>として使用されます。

  • <topic_branch>:

    • これは、移動対象のコミットが含まれるブランチまたは特定のコミットを指定します。
    • Gitは、この<topic_branch>が指すコミットから<upstream_base>までを遡って、移動対象のコミット範囲を決定します。
    • 通常は、現在作業しているブランチを指定するか、省略して現在のブランチ（HEAD）を対象とすることが多いです。別のブランチのコミットを移動させたい場合に、そのブランチ名を指定します。
    • この引数も省略可能です。省略した場合、現在のブランチ（HEAD）が対象となります。

これらの引数を理解することで、git rebase --ontoが「<upstream_base>から<topic_branch>までのコミット群を、<new_base>の直後に移動する」という操作であることが分かります。

さて、この構文を理解した上で、具体的な使用例を見ていきましょう。例を通じて、それぞれの引数がどのように使われるのかがより明確になるはずです。

git rebase --ontoの具体的な使い方と例

git rebase --ontoは様々なシナリオで役立ちますが、ここでは特に一般的な使い方をいくつか紹介します。

例1：特定のコミット範囲だけを別のブランチに移動する

これはrebase --ontoの最も典型的な使用例の一つです。例えば、以下のようなコミット履歴があるとします。

A -- B -- C -- D -- E (main)
\
F -- G -- H (feature)

ここで、featureブランチで作業しているとします（HEADはfeatureブランチ）。通常、git rebase mainとすると、F, G, Hの全てのコミットがmainの先端（コミットE）の上に移動します。

“`bash

featureブランチにいるとして

git rebase main
“`

結果：

A -- B -- C -- D -- E (main)
\
F' -- G' -- H' (feature)

しかし、もしfeatureブランチに含まれるコミットのうち、GとHだけを、developという別のブランチの先端（例えばコミットI）の上に移動したい場合はどうでしょうか？履歴は以下のようになっているとします。

A -- B -- C -- D -- E (main)
\ \
F -- G -- H (feature)
\
I (develop) # developブランチの最新コミット

移動したいのはGとHです。移動先の新しいベースはdevelopの先端（コミットI）です。移動対象の範囲の始点はFの次からなので、<upstream_base>としてコミットFを指定します。移動対象のコミットが含まれるブランチはfeatureです。

このシナリオにおけるコマンドは以下のようになります。現在いるブランチはfeatureでも、developでも構いませんが、操作対象となるのはfeatureブランチに含まれるコミット群なので、コマンドの最後の引数（<topic_branch>）としてfeatureを指定します。

“`bash

現在どのブランチにいてもOKだが、ここではmainにいると仮定

git rebase –onto develop F feature
“`

  • <new_base>: develop (移動先の新しいベース)
  • <upstream_base>: F (移動しないコミットの境界。Fより新しいコミットを対象とする)
  • <topic_branch>: feature (移動対象のコミットが含まれるブランチ)

このコマンドを実行すると、以下のステップが行われます。

  1. Gitは、featureブランチの履歴のうち、コミットFよりも新しいコミット（G, H）を特定します。
  2. 特定されたコミット（G, H）を一時的な領域に保存します。
  3. コマンドの最後にブランチ名（feature）が指定されているため、featureブランチのHEADを、<new_base>で指定されたdevelopの先端（コミットI）に移動させます。
  4. 一時保存しておいたコミット（G, H）を、新しいHEAD（コミットI）の上に順番に再適用します。

結果として、履歴は以下のようになります。

A -- B -- C -- D -- E (main)
\
F (feature) # ここでfeatureブランチは止まったまま
\
I (develop)
\
G' -- H' (feature) # featureブランチのHEADがIの上に移動し、G', H'が追加された

ポイント: <topic_branch>をコマンドの最後に指定した場合、そのブランチのHEADが新しいベースに移動します。もし現在のブランチ（HEAD）のコミットを移動させたいが、現在のブランチのHEAD自体は動かしたくない場合は、<topic_branch>を省略するか、別の方法を検討する必要があります（例: git checkout で一時的に別のブランチに切り替える、あるいは git branch <new_branch> <upstream_base> で古い時点のブランチを作成し、そちらに対して --onto するなど）。しかし、上記の例のように特定のブランチの一部コミットを移動してそのブランチのHEADを新しい場所に付け替えたい場合は、このように<topic_branch>を指定するのが標準的です。

例2：ブランチを分割する (Interactive Rebase との組み合わせ)

一つのブランチで複数の機能や修正を開発してしまい、後からそれらを別々のブランチに分けたい、というシナリオはよくあります。これもgit rebase --onto、特にインタラクティブモード (-i) と組み合わせることで効率的に実現できます。

例えば、以下のような履歴で、featureブランチには機能Aに関連するコミット (FA1, FA2) と機能Bに関連するコミット (FB1, FB2) が混在しているとします。

A -- B -- C (main)
\
FA1 -- FB1 -- FA2 -- FB2 (feature)

ここで、featureブランチから機能Aだけを含むfeature-Aブランチと、機能Bだけを含むfeature-Bブランチを作成したいとします。どちらの新しいブランチも、ベースはmainの先端（コミットC）としたいです。

手順:

  1. 現在のブランチ（feature）を保護する: 万が一に備え、現在の状態を指すタグやブランチを残しておくと安全です。あるいは、単にそのままにしておき、新しいブランチを作成後に元のfeatureブランチは削除またはリセットすることもできます。ここでは、featureブランチはそのままにしておき、新しいブランチを作成・操作することにします。

  2. 機能A用の新しいブランチを作成し、rebase –onto -i を実行:

    • 新しいブランチfeature-Aを、元のfeatureブランチのベースとなったコミット（ここではmainの先端、コミットC）から分岐させます。
      bash
      git checkout -b feature-A main
    • これでfeature-AブランチはコミットCを指しています。
    • 次に、元のfeatureブランチから機能Aに関連するコミット (FA1, FA2) だけを、現在のfeature-AブランチのHEAD（コミットC）の上に移動させます。
    • 移動対象の範囲は、featureブランチの、mainとの共通の祖先（コミットB）からfeatureの先端（コミットFB2）までです。この範囲に含まれるコミットはFA1, FB1, FA2, FB2です。
    • <new_base>は現在のfeature-AブランチのHEAD、つまりコミットCです。
    • <upstream_base>はfeatureブランチがmainから分岐したコミット、つまりコミットBです。
    • <topic_branch>は元のfeatureブランチです。

    “`bash

    feature-Aブランチにいる状態で実行

    git rebase -i –onto HEAD B feature

    または、より明確に指定する場合

    git rebase -i –onto feature-A B feature

    あるいは、mainの先端をnew_baseとするなら

    git rebase -i –onto main B feature

    (feature-Aがmainの先端を指しているなら同じ)

    ``
    *    :HEAD(現在のfeature-Aブランチの先端、つまりコミットC)
    *    :B(移動対象外とするコミットの境界。Bより新しいfeatureブランチのコミットが対象)
    *    :feature` (移動対象のコミットが含まれるブランチ)

    このコマンドを実行すると、エディタが開かれ、<upstream_base> (B) から <topic_branch> (feature, つまりFB2) までのコミット、すなわちFA1, FB1, FA2, FB2がリストアップされます。

    “`
    pick fa1fa1f Function A part 1
    pick fb1fb1f Function B part 1
    pick fa2fa2f Function A part 2
    pick fb2fb2f Function B part 2

    Rebase B..feature onto ccccccc (main)

    … （ヘルプメッセージなど）

    ``
    * ここで、機能Aに関連するコミット (    FA1,FA2) 以外の行 (FB1,FB2`) を削除します。

    pick fa1fa1f Function A part 1
    pick fa2fa2f Function A part 2
    * エディタを保存して閉じると、Gitはこれらの選択されたコミットだけを、<new_base> (feature-AのHEAD, コミットC) の上に順番に再適用します。

    結果：feature-Aブランチは以下のようになります。

    A -- B -- C (main)
    \
    FA1' -- FA2' (feature-A)

    元のfeatureブランチは変更されていません。

  3. 機能B用の新しいブランチを作成し、同様に rebase –onto -i を実行:

    • 同様に、新しいブランチfeature-Bをmainの先端（コミットC）から分岐させます。
      bash
      git checkout -b feature-B main
    • feature-Bブランチにいる状態で、元のfeatureブランチから機能Bに関連するコミット (FB1, FB2) だけを移動させます。
      “`bash

    feature-Bブランチにいる状態で実行

    git rebase -i –onto HEAD B feature

    または

    git rebase -i –onto feature-B B feature

    ``
    * エディタが開いたら、機能Bに関連するコミット (    FB1,FB2) 以外の行 (FA1,FA2`) を削除します。

    pick fb1fb1f Function B part 1
    pick fb2fb2f Function B part 2
    * エディタを保存して閉じると、Gitはこれらの選択されたコミットだけを、<new_base> (feature-BのHEAD, コミットC) の上に再適用します。

    結果：feature-Bブランチは以下のようになります。

    A -- B -- C (main)
    \
    FB1' -- FB2' (feature-B)

    最終的な履歴のイメージ：

    “`
    A — B — C (main)
    / |
    / |
    / \
    / \
    / \
    FA1′–FA2′ FB1′–FB2′
    (feature-A) (feature-B)

    元のfeatureブランチはそのまま残っているか、必要なら削除/リセットする

    … — FA1 — FB1 — FA2 — FB2 (feature)

    “`

この例のように、git rebase -i --ontoを使うことで、元のブランチのコミット履歴を破壊することなく（ただし、新しいブランチ上でのみ履歴が変わる）、特定のコミット範囲を選択し、新しいベースの上に付け替えることができます。インタラクティブモード (-i) を併用することで、コミットの順序変更、結合 (squash/fixup)、編集 (edit)、削除 (drop) なども同時に行うことが可能です。これは、汚くなった履歴を整形し、意味のある単位でコミットを整理し直すのに非常に強力な方法です。

例3：別のブランチから来たコミットを整理して自分のブランチに持ってくる

別の開発者が別のブランチで作業した内容の一部を、自分のブランチに取り込みたいが、単にマージするのではなく、自分のブランチの履歴をシンプルに保ちたい、というケースも考えられます。cherry-pickを繰り返す方法もありますが、複数の連続したコミットを取り込みたい場合はrebase --ontoがより効率的です。

例えば、以下のような履歴があるとします。

A -- B -- C (main)
\ \
D -- E (feature)
\
F -- G -- H (another_feature)

featureブランチにいるとして、another_featureブランチに含まれるコミットのうち、GとHだけを、現在のfeatureブランチの先端（コミットE）の上に持ってきたいとします。

この場合、<new_base>は現在のブランチのHEAD、つまりコミットEです。移動対象のコミットはanother_featureブランチに含まれるGとHです。この範囲の始点はFの次からなので、<upstream_base>としてコミットFを指定します。移動対象のコミットが含まれるブランチはanother_featureです。

“`bash

featureブランチにいる状態で実行

git rebase –onto HEAD F another_feature

または

git rebase –onto feature F another_feature

“`

  • <new_base>: HEAD (現在のfeatureブランチの先端、コミットE)
  • <upstream_base>: F (移動対象外とするコミットの境界。Fより新しいanother_featureブランチのコミットが対象)
  • <topic_branch>: another_feature (移動対象のコミットが含まれるブランチ)

このコマンドを実行すると、another_featureブランチの履歴のうち、コミットFよりも新しいコミット（G, H）が特定され、一時保存されます。次に、現在のブランチ（feature）のHEADはそのまま（コミットEを指したまま）で、一時保存しておいたコミットGとHが、featureブランチの先端（コミットE）の上に再適用されます。

結果として、履歴は以下のようになります。

A -- B -- C (main)
\ \
D -- E (feature)
\
G' -- H' (feature) # G', H'がfeatureブランチに追加された
\
F -- G -- H (another_feature) # another_featureブランチは変更なし

このように、git rebase --ontoは、別のブランチから特定のコミット範囲だけを抜き出し、現在のブランチの先端に導入する際にも使用できます。これはcherry-pick G Hとほぼ同じ結果になりますが、rebase --ontoは対象が複数の連続したコミットである場合に構文がシンプルになるという利点があります。

例4：<upstream_base>の指定と範囲指定の詳細

git rebase --onto <new_base> <upstream_base> <topic_branch> における <upstream_base> は、「<upstream_base>より新しく、かつ<topic_branch>に含まれるコミット」という範囲指定の基準点として機能します。これはGitの範囲指定構文 <upstream_base>..<topic_branch> と似ていますが、いくつか重要な点があります。

<upstream_base>は、必ずしも<new_base>と<topic_branch>の共通の祖先である必要はありません。単に「このコミットは移動せず、これよりも新しいコミットを移動対象とする」という境界線として機能します。

例として、以下のような履歴を考えます。

L -- M -- N (main)
\
O -- P -- Q (feature)

ここで、featureブランチのコミットPとQだけを、mainブランチの先端（コミットN）の上に移動したいとします。

  • <new_base>: main (コミットN)
  • 移動したいコミットはPとQです。これらはfeatureブランチに含まれています。移動対象の始点はOの次からなので、<upstream_base>はOを指定します。
  • <topic_branch>: feature (コミットQ)

コマンドは以下のようになります。

“`bash

featureブランチにいるとして

git rebase –onto main O feature
“`

  • <new_base>: main (移動先の新しいベース)
  • <upstream_base>: O (移動しないコミットの境界。Oより新しいfeatureブランチのコミットが対象)
  • <topic_branch>: feature (移動対象のコミットが含まれるブランチ)

実行されると、featureブランチの履歴のうち、コミットOよりも新しいコミット（P, Q）が特定され、一時保存されます。featureブランチのHEADはmainの先端（コミットN）に移動し、保存しておいたP, Qがその上に再適用されます。

結果：

L -- M -- N (main)
\ \
O (feature) # featureブランチはOを指したままか？
\
P' -- Q' (feature) # featureブランチのHEADがNの上に移動し、P', Q'が追加された

コマンドの最後の引数<topic_branch>にブランチ名を指定した場合、そのブランチの参照（HEAD）が新しいベースに移動し、そのブランチが指していたコミットのうち移動対象となったものが新しいベースの上に再構築されます。一方、<topic_branch>を省略した場合（つまりgit rebase --onto <new_base> <upstream_base>とした場合）、対象となるのは現在のブランチ（HEAD）のコミット群となり、現在のブランチのHEADが新しいベースに移動します。

この例では、git rebase --onto main O featureを実行すると、featureブランチのHEADは最終的にQ'を指すようになります。元のfeatureブランチが指していたコミットOは、mainとfeatureの新しい分岐点のように見えますが、厳密には元のコミット履歴は残ったままで、featureというブランチ名が新しいコミットQ'を指すように更新された、という挙動になります。

<upstream_base>..<topic_branch> という範囲指定は、git log <upstream_base>..<topic_branch> で確認できるコミットの集合と概ね一致しますが、rebase --ontoではもう少し複雑な内部処理（特にマージコミットの扱いなど）が行われることがあります。しかし、基本的には「<upstream_base>を含まず、<topic_branch>を含む範囲」を対象と理解しておけば、多くの場合は適切にコマンドを使用できます。

もし移動させたいコミット群が、共通の祖先から連続している場合は、通常のgit rebase <new_base>でも実現できるケースがあります。例えば、上記の例でO, P, Q全てをmainの上に移動したい場合は、git rebase main featureとすれば実現できます。（現在のブランチがfeatureの場合はgit rebase mainでも同じ）

しかし、<upstream_base>を指定することで、移動させたくないコミット（例: 上記のO）を範囲から除外し、「その次から」を移動対象とすることができるのが--ontoの強力な点です。

git rebase --onto 使用時の注意点

git rebase --ontoは非常に強力なツールですが、履歴を書き換えるコマンドであるため、使用には慎重さが求められます。特に以下の点に注意が必要です。

  1. 公開済み（共有）ブランチに対するrebase: git rebaseの最大の注意点です。リモートリポジトリにプッシュされ、他の開発者と共有しているブランチに対してrebaseを行うと、そのブランチ上のコミットIDが変更されます。他の開発者が既に古いコミットIDに基づいた作業をしている場合、プッシュ/プル時に履歴の食い違いが発生し、コンフリクトや混乱の原因となります。

    • 原則: 公開済みの共有ブランチに対してはrebaseを使用しない。代わりにgit mergeを使用してください。
    • 例外: 自分のローカルブランチをリモートにプッシュしたが、まだ他の誰もその変更を取り込んでいないことが確実な場合に限り、rebase後にgit push --forceまたはgit push --force-with-leaseを使用してリモートの履歴を上書きすることが許容される場合があります。しかし、--forceは非常に危険なので、--force-with-leaseを使うことを強く推奨します。--force-with-leaseは、リモートの履歴がローカルでrebaseする前に取得した状態から変化していないことを確認してからプッシュするため、他の開発者が知らない間に変更を加えている可能性を減らせます。

  2. コンフリクトの解決: rebaseはコミットを一つずつ再適用していくプロセスです。各コミットを再適用する際に、そのコミットの変更内容と新しいベースの変更内容が衝突（コンフリクト）する可能性があります。コンフリクトが発生した場合、Gitはその時点で処理を中断し、ユーザーに解決を求めます。

    • コンフリクトを解決する手順は以下の通りです。
      1. コンフリクトが発生したファイルを開き、Gitがマーカーで示した箇所を編集してコンフリクトを解消します。
      2. 解決したファイルをステージングエリアに追加します (git add <file>)。
      3. git rebase --continueを実行して、rebaseプロセスを再開します。
    • もしrebaseを中止したい場合は、git rebase --abortを実行します。これにより、rebase開始前の状態に戻すことができます。
    • 特定のコミットの適用をスキップしたい場合は、コンフリクト解決後にgit rebase --skipを実行します。ただし、これはそのコミットで行われた変更を完全に破棄することになるため、慎重に使用してください。

  3. git reflogの活用: rebaseのような履歴を書き換える操作は、意図しない結果になった場合に元の状態に戻すのが難しいと感じられるかもしれません。しかし、Gitにはgit reflogという強力なコマンドがあります。

    • git reflogは、リポジトリのHEADが過去にどのコミットを指していたかの履歴を記録しています。つまり、あなたが実行したほとんど全てのGit操作（コミット、マージ、リベース、リセットなど）の前後でHEADが指していた場所を確認できます。
    • もしrebaseで失敗したり、結果が意図通りにならなかったりした場合、git reflogでrebaseを実行する直前のHEADのコミットIDを確認し、git reset --hard HEAD@{n} (nはreflogのリストにおける該当操作のインデックス) または git reset --hard <commit_id> を実行することで、rebase前の状態に簡単に戻ることができます。
    • reflogはデフォルトではローカルリポジトリにのみ記録され、通常は一定期間（デフォルトでは90日）後に期限切れとなります。

  4. <upstream_base>と<topic_branch>の正しい理解: git rebase --onto <new_base> <upstream_base> <topic_branch> の引数の意味、特に<upstream_base>と<topic_branch>が指定する範囲を正確に理解することが重要です。

    • <upstream_base>は「このコミットより新しい」という範囲の始点です。このコミット自体は移動対象に含まれません。
    • <topic_branch>は「このコミットまで」という範囲の終点です。このコミット自体は移動対象に含まれます（ただし、<upstream_base>から<topic_branch>までの間にマージコミットなどが含まれる場合、それらの扱いは少し複雑になることがあります。しかし、多くの場合、直線的な履歴であれば単純な範囲指定として機能します）。
    • 特に<topic_branch>にブランチ名を指定した場合、そのブランチのHEADが最終的に<new_base>の上に移動した結果を指すようになります。現在のブランチのコミットを移動させたいが、現在のブランチは元の場所に残しておきたい場合は、<topic_branch>を省略するか、移動させたいコミット範囲の終点を明示的に指定する（例: git rebase --onto <new_base> <upstream_base> <commit_id>）などの工夫が必要です。

  5. インタラクティブモード (-i) の検討: rebase --ontoで複数のコミットを移動させる場合、インタラクティブモード (-i) を併用することを強く推奨します。これにより、移動するコミットを細かく選択したり、移動中にコミットを編集・整理したりすることができます。これは、歴史をよりクリーンで理解しやすいものにするために非常に役立ちます。git rebase -i --onto <new_base> <upstream_base> <topic_branch>という形で使用します。

git rebase --ontoと他のコマンドとの比較

git rebase --ontoと同様に、あるブランチから別のブランチへコミットを移動させる（コピーする）機能を持つコマンドとして、git cherry-pickがあります。両者は似ていますが、目的や適用される状況が異なります。

  • git cherry-pick <commit_id>...:

    • 指定した個別のコミットを、現在のブランチの先端にコピーするコマンドです。
    • 履歴は直線的になりません。コピー元のコミットとコピー先の新しいコミットは異なるコミットIDを持ち、それぞれ別の場所に存在します。
    • 主に、他のブランチにある一つまたは数個のコミットを、自分のブランチに一時的に取り込みたい場合などに使用されます。
    • 連続していないコミットや、特定のコミットだけを選択的に取り込みたい場合に便利です。
    • 複数のコミットをcherry-pickする場合、一つずつ適用されるため、それぞれのコミットでコンフリクトが発生する可能性があります。

  • git rebase --onto <new_base> <upstream_base> <topic_branch>:

    • 指定したコミット範囲を、<new_base>の直後に付け替えるコマンドです。
    • 指定したブランチ（または現在のブランチ）のHEADが新しい場所に移動します。
    • 移動対象となったコミットは、親コミットが変わるため新しいコミットIDを持ちますが、元の履歴は（ブランチ参照が移動したことを除けば）残ったままです。
    • 主に、あるブランチに含まれる連続したコミット群を、別の場所に移動させたり、履歴を整理・分割したりする場合に使用されます。
    • 複数のコミットをrebaseする場合、まとめて一連の操作として処理されます。コンフリクトは発生したコミットで一時停止し、解決後に--continueで再開します。

使い分けの目安:

  • 数個のバラバラなコミットを、現在のブランチに「コピー」して取り込みたい場合はcherry-pick。
  • あるブランチ上の特定の「コミット範囲」を、別のブランチの先端に「移動」させて、そのブランチの履歴を付け替えたい場合はrebase --onto。特に、移動中にコミットの整理や編集も行いたい場合はrebase -i --onto。

実践的なシナリオと rebase --onto の活用

これまで紹介した例以外にも、git rebase --ontoは様々な実践的なシナリオで活用できます。

  1. 古いトピックブランチを最新のmainに合わせて整理する:
    長期間開発していたfeatureブランチがあり、その間にmainブランチには多数の変更が取り込まれたとします。featureブランチをmainにマージする前に、featureブランチの履歴を最新のmainの上に付け替え、コンフリクトを事前に解消しておきたい場合。

    “`bash

    featureブランチにいるとして

    git fetch origin main # 最新のmainを取得
    git rebase –onto origin/main main feature
    ``
    *    :origin/main(リモートの最新main)
    *    :main(ローカルのmain。rebase前にfeatureが分岐した時点のmainを指していると仮定)
    *    :feature` (現在のブランチ)

    これは、featureブランチの、ローカルのmainから分岐した時点より新しい全てのコミットを、リモートの最新mainの上に付け替える操作です。もしローカルのmainが古い場合でも、--ontoを使えば新しいベースを明示的に指定できます。ただし、これは一般的なgit rebase mainと結果的に同じになることが多いです（ローカルのmainが最新であれば）。--ontoを使うことで、例えば「ローカルのmainから分岐した時点」ではなく、「特定のタグAが打たれたコミット」から「現在のfeatureブランチのHEAD」までのコミットを、「最新のmainブランチ」の上に移動させる、といった柔軟な指定が可能になります。

  2. 開発中のブランチから特定の部分だけを早期に提出する（後から分割）：
    一つのブランチで複数の関連する機能や修正に取り組んでいるが、そのうちの一つだけを先にレビューに出したい場合。上記のブランチ分割の例と同様に、rebase -i --ontoを使って、提出したい機能に関連するコミットだけを新しいブランチに切り出し、ベースブランチの先端に付け替えることで実現できます。

  3. 複雑な履歴を持つ外部リポジトリからの変更を取り込みつつ、自分の変更を整理する:
    Upstreamリポジトリからフォークしたプロジェクトで作業しており、Upstreamの変更を自分のmasterブランチに取り込み、さらに自分のfeatureブランチをそのmasterにrebaseしたいが、Upstreamの履歴が複雑だったり、自分のmasterブランチにUpstream以外のコミットも含まれていたりする場合。rebase --ontoを使って、自分のfeatureブランチのコミットを、最新のUpstreamのmasterの先端の上に移動させる、といったより精密な制御が可能になります。

これらのシナリオでは、git rebase --ontoが単なるrebase <base>では実現できない細かいコミット範囲の指定や、移動先の柔軟な指定を可能にすることで、複雑な状況でも変更履歴を整理し、より理解しやすい状態に保つために役立ちます。

まとめ：git rebase --ontoの理解と活用

git rebase --ontoは、Gitのrebaseコマンドを拡張し、コミットの「付け替え」操作をより柔軟に行うための強力なオプションです。

基本的な構文は git rebase --onto <new_base> <upstream_base> <topic_branch> であり、その核心は以下の3つの引数の役割にあります。

  • <new_base>: コミット群を移動させる新しいベースとなる場所（コミットまたはブランチ）。移動対象のコミットはこの直後に配置されます。
  • <upstream_base>: 移動対象のコミット範囲を指定する境界線となるコミット。「このコミットより新しい」コミットが移動対象となります。
  • <topic_branch>: 移動対象のコミットが含まれるブランチまたはコミット。通常はこのブランチの履歴から<upstream_base>より新しい部分が選択されます。コマンドの最後に指定された場合、このブランチのHEADが<new_base>の上に移動した結果を指すようになります。

このコマンドを使うことで、単に現在のブランチを別のブランチの先端に移動させるだけでなく、以下のようなより複雑なシナリオに対応できます。

  • あるブランチに含まれるコミットのうち、特定の範囲だけを移動する。
  • 移動先のベースを特定のコミットやタグに指定する。
  • 一つのブランチで複数の作業を行った結果を、後から機能ごとに別のブランチに分割・整理する。

特に、インタラクティブモード (-i) と組み合わせたgit rebase -i --ontoは、移動対象のコミットを選択・編集・削除・結合しながら付け替えを行うことができ、汚れた履歴をクリーンアップする上で非常に強力なツールとなります。

ただし、git rebase --ontoは履歴を変更するコマンドであるため、公開済みの共有ブランチに対して使用するのは避けるべきです。これにより、他の開発者との間で履歴の不整合が発生し、混乱を招く可能性があります。個人的なブランチや、まだ共有していないブランチでの使用に限定するか、チーム内でrebaseの運用ルールを明確に定めた上で、git push --force-with-leaseなどを慎重に使用する必要があります。

また、rebase中にコンフリクトが発生した場合は、適切に解決し、git rebase --continueで進める必要があります。予期せぬ結果になったり、操作を間違えたりした場合でも、git reflogコマンドを使えばrebase前の状態に戻すことができることを覚えておきましょう。

git rebase --ontoは、最初は少し複雑に感じるかもしれませんが、その仕組みと引数の意味を理解すれば、Gitを使った開発ワークフローにおいて履歴を柔軟に操作し、よりクリーンで管理しやすい状態に保つための非常に強力な味方となります。ぜひ、安全な環境（ローカルの実験用リポジトリなど）で実際にコマンドを実行し、その挙動を体験してみてください。

Gitの公式ドキュメントや、他の信頼できるリソースも参照しながら理解を深めることで、git rebase --ontoを効果的に活用できるようになるでしょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール