Git を使っていると、必ず直面するのが「ブランチをどう統合するか」という問題です。大きく分けて rebase と merge という二つの方法があります。どちらも「履歴を統合する」という目的は同じですが、動きと履歴の見え方に違いがあるため、使いどころを間違えるとチーム全体に混乱を招きます。ここでは現場で最低限おさえておくべき勘所を整理します。
rebase の勘所
rebase は「自分のブランチのコミットを、指定したブランチの先頭に積み直す」操作です。履歴が一本に整理され、後からログを読むと「main の上に自分の作業がきれいに積まれている」状態になります。
利点は 履歴が直線的になり、レビューや追跡がしやすいこと。開発中に細切れコミットを rebase -i で整理し、論理的な単位にまとめてからプッシュすれば、履歴がすっきりします。
ただし欠点は 既存コミットのハッシュが変わること。既に他の人が共有しているブランチで rebase すると、履歴が食い違い、強制 push が必要になって衝突が増えるリスクがあります。そのため 自分のローカル作業ブランチで使うのが原則 です。
merge の勘所
merge は「二つのブランチの内容をまとめて統合する」操作です。履歴上は枝分かれと合流が残るため、作業の経緯を忠実に保存できます。
利点は 既存のコミットハッシュを壊さない安全性。他人と共有しているブランチでも安心して使えます。
一方で、履歴は枝分かれが増えやすく、ログが複雑になるという欠点があります。そのため長期的に履歴を読み返すと「どの変更がどの流れで入ったのか」がやや分かりにくくなることもあります。
実務では 共有リポジトリに統合するときのデフォルト として選ばれることが多いです。
実務での使い分け
勘所を一言でまとめると、
自分の作業を整理するなら rebase
他人と共有した後は merge
これに尽きます。
例えば feature ブランチを main に追従させる場合、自分しか触っていないうちは git rebase origin/main で履歴を整えると後が楽になります。逆にレビュー中のブランチや、複数人が参照しているブランチを rebase するのは避け、git merge で取り込む方が安全です。最終的に main に統合するときも、コミットを残したいなら merge、細切れをまとめたいなら squash merge などを選択すれば良いでしょう。
まとめ
rebase は「履歴をきれいにする道具」。ただし公開済みのブランチには使わない。
merge は「安全に統合する道具」。履歴は複雑になるが、衝突リスクが少ない。
基本原則は ローカルで rebase、共有後は merge。
この勘所さえ押さえておけば、チーム開発でも大きなトラブルは避けられるはずです。
入会申込
ログイン
