Git rebase ブランチ: 安全にリベースする方法を段階的に説明します

ブランチをリベースするには、フェッチしてブランチに切り替え、新しいベースでリプレイします: `git fetch origin`、`git switch topic`、`git rebase origin/main`。 Git はブランチ自体のコミットを脇に置き、ブランチを origin/main の先端に移動し、コミットを一度に 1 つずつ再適用します。履歴はマージ コミットなしで直線のままです。再生されたコミットはすべて新しいハッシュを取得するため、すでにプッシュしたブランチにはその後 git push --force-with-lease が必要です。

git rebase はブランチに対して何をしますか?

たとえば、topic には独自のコミットが 2 つあり、ブランチの開始以来、main には 3 つのコミットが追加されたとします。リベースすると、main をブランチにマージせずに、その開始点が更新されます。

# before
A---B---C---D---E   origin/main
     \
      F---G         topic

# after git rebase origin/main
A---B---C---D---E   origin/main
                 \
                  F'---G'   topic

F' と G' は、F と G と同じ変更とメッセージを保持しますが、親が変更されたため、新しいハッシュを持つ新しい commit になります。同じ開始点からマージすると、両方の行が保持され、2 つの親を持つ 1 つのコミットが追加されます。 マージとリベース に関するレッスンでは、両方を 1 つのグラフに示しています。

ブランチを段階的に安全にリベースするにはどうすればよいですか?

まず検査し、古いチップを保持し、再生してからテストします。最初の 3 つのコマンドは何も書き換えません。

# 1. update origin/main, your files stay as they are
git fetch origin

# 2. list the commits Git will replay
git log --oneline origin/main..topic

# 3. keep a name on the old tip
git branch topic-backup topic

# 4. replay
git switch topic
git rebase origin/main

リストに見覚えのないコミットがある場合は、ステップ 2 で停止します。これは、ブランチが思った場所から開始されていないことを意味するためです。リベースが終了したら、git status を実行して終了を確認し、テストを実行します。競合のないリベースでも動作が中断される可能性があります。

毎回ベースに名前を付けます。裸の git rebase はブランチの上流を使用します。これは多くの場合、main ではなく origin/topic です。別の機能ブランチから開始したブランチを移動するには、古いベースにも git rebase --onto main old-base topic という名前を付けます。 未公開作品のリベース に関するレッスンでは、実際のグラフでこれを実践します。

リベース中の競合を修正するにはどうすればよいですか?

Git はコミットを一度に 1 つずつ適用するため、同じ行であっても複数回停止する可能性があります。後のコミットはまだ適用されていないため、Git が停止したコミットのみを修正します。

# edit the file and remove the conflict markers, then
git add path/to/file
git rebase --continue

同じ競合を頻繁に繰り返す場合、git config rerere.enabled true は解決策を記録し、それを再利用します。昨日の答えが今日のコードで間違っている可能性があるため、再利用された各結果を確認してください。 続行、スキップ、中止 に関するレッスンでは各ケースについて説明し、マージ競合を解決する方法 ではマーカーの読み取りについて説明します。

プッシュする前にリベースを確認するにはどうすればよいですか?

他の人が見る前に、古いシリーズと新しいシリーズを比較します。

# old and new commits, matched pair by pair
git range-diff origin/main topic-backup topic

# everything the branch adds to main, as one diff
git diff origin/main...topic

# the shape of the history
git log --graph --oneline --decorate origin/main topic

git range-diff は、競合解決によってパッチが変更されたとき、またはコミットが欠落したときを示します。コンパイルされたコードでは、ドロップされたテストや変更された条件が隠蔽される可能性があり、ここでそれを検出します。

リベースを元に戻すにはどうすればよいですか?

実行中は、git rebase --abort を使用します。それが完了したら、ブランチを古い先端に戻します。 --hard はコミットされていない変更を破棄するため、最初に git status を確認してください。

git reset --hard topic-backup

# no backup? find the old tip in the reflog
git reflog show topic
git reset --hard <old-tip-hash>

リセット、リベース、またはコミットを元に戻す のガイドでは、reflog についてさらに詳しく説明しています。

リベースされたブランチをプッシュするにはどうすればよいですか?

リモート ブランチが古いコミットを保持しており、Git は非早送り更新を認識するため、通常のプッシュは拒否されます。置き換えようとしているものを確認してから、リースをプッシュします。

git fetch origin
git log --oneline topic..origin/topic
git push --force-with-lease origin topic

その git log には古いコミットのみがリストされます。それ以外のことはチームメイトの仕事なので、止めて最初に持ち込んでください。 --force-with-lease は、最後のフェッチで参照された場所にリモート ブランチがまだある場合にのみリモート ブランチを置き換えます。プレーンな --force にはそのようなチェックはありません。バックグラウンドでの取得によりその値が更新されるため、スクリプトは期待するコミットに git push --force-with-lease=topic:<expected-hash> origin topic という名前を付けることができます。

このブランチをリベースするかマージする必要がありますか?

ブランチのリベース のガイドにはあらゆるオプションがあり、リースを使用した強制プッシュ ではプッシュについて説明しています。途中で潰したり、言い換えたり、並べ替えたりするには、GUI での対話型リベース をお読みください。