フィーチャーブランチが main より遅れていて、新しい変更が必要です。Git mergeとrebaseは、それを取り込む2つの方法の選択で、どちらも正しい方法です。違いは、その後の履歴の見た目にあります。

小さなリポジトリを作って両方のコマンドを実行し、実際の出力を下に貼りました。想像ではなく結果を比べられます。Gitが初めての方は、まず初心者向けGitチュートリアル（英語）をご覧ください。

git mergeとgit rebaseの役割

git merge は2つのブランチの先頭を取り、1つにまとめます。両方に新しいコミットがある場合、Gitは親が2つのマージコミットを作ります。すでにあるものは何も変更されません。

git rebase は自分のブランチだけにあるコミットをいったん脇に置き、ブランチを相手の先頭に移動してから、コミットを1つずつ再適用します。再適用されたコミットは、変更内容は同じでも新しいハッシュを持つ新しいコミットです。

git mergeの実践

出発点は次のとおりです。main にコミットA、feature に2つのコミット（F1、F2）があり、その後 main にもう1つのコミット（M1）が追加されました。ここで main を feature にマージします。

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

グラフは実際の経緯を示しています。2本の作業ラインが合流しました。元のコミットF1とF2はハッシュを保ちます。代償はマージコミットが1つ増えることで、活発なプロジェクトではグラフが網の目のようになります。

git rebaseの実践

出発点は同じですが、今度は feature を main の上にrebaseします。

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

履歴は一直線になり、まるでM1の後に作業を始めたかのようです。ハッシュに注目してください。F1は 5a71e3c から bf9149e に、F2は 082cc6a から 1ff474b に変わりました。Gitがそれらを書き換えたためで、rebaseに注意が必要な理由です。

mergeとrebaseの比較

rebaseの黄金律

自分のリポジトリの外に存在するコミットをrebaseしてはいけません。rebaseの後、ブランチはサーバー上のコピーと一致しなくなるため、プッシュには強制が必要になります。同僚が古いコミットを土台に作業していた場合、その履歴はあなたの履歴と食い違い、解消は大変です。

自分専用のフィーチャーブランチをrebaseするのは問題ありません。main や他の人が使うブランチをrebaseするのはいけません。

安全なチームワークフロー

この手順なら、誰も驚かせずに履歴をきれいに保てます。多くのチームがCIパイプラインの前に使っている方法でもあり、GitHub Actions CI/CDガイド（英語）のパイプラインもその一例です。

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease は、前回のfetch以降に誰かがサーバーのブランチへプッシュしていた場合、上書きを拒否します。通常の --force は黙ってそれを消してしまいます。プルリクエストが承認されたら、main にマージします。

失敗したrebaseを元に戻す方法

rebaseは破壊的に見えますが、古いコミットはしばらくGitの reflog に残るので、元に戻せます。

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

リスクのあるrebaseの前に git branch backup でバックアップブランチを作っておけば、復旧は1コマンドで済みます。コンテナでデータベースやツールを動かしていますか？初心者向けDockerチュートリアル（英語）もご覧ください。

まとめ

mergeは事実を残し、rebaseは履歴を整えます。自分のブランチを最新にするにはrebase、成果を届けるにはmergeを使い、他の人が依存している履歴は決して書き換えないでください。

よくある質問

さらに学ぶ（英語の記事）