はじめに
git rebase main は、複数人で開発しているときに自分の作業ブランチを最新のmainに追従させるためのコマンドです。
「git merge じゃダメなの？」
「rebaseって履歴が書き換わるって聞いたけど怖い…」
そんな疑問を持つ方向けに、この記事では git rebase main を使う理由・タイミング・注意点をわかりやすく紹介します。
mainから分岐したまま作業していると…
例えば以下のように main に新しいコミットが追加されたとします：
A---B---C (main)
\
D---E (feature/my-task)
このまま feature/my-task をPRとして出すと、古いmainに基づいたコードがレビューされてしまい、最新の状態と衝突する可能性があります。
解決策：最新のmainに追従させる
$ git fetch origin
$ git rebase origin/main
これにより以下のように履歴が付け替わります：
A---B---C (main)
\
D'--E' (feature/my-task)
※ D と E の内容はそのまま、親が最新のCに変更されたイメージです。
mergeとの違い
| 比較項目 | git merge main |
git rebase main |
|---|---|---|
| 履歴の見た目 | マージコミットが入る（分岐が見える） | 線形（シンプルな1本線）になる |
| 利用の目的 | 変更を取り込む | 履歴を整理して追従させる |
| コンフリクト時の修正順 | 自分の作業内容 vs main | mainの変更 vs 自分の作業内容 |
| チーム開発での使用 | PR前の整理には不向き | PR前の整理に◎（レビューしやすい） |
rebase の使い方（基本）
# 1. 最新mainを取得
$ git fetch origin
# 2. 作業ブランチでrebase
$ git checkout feature/my-task
$ git rebase origin/main
コンフリクトが出たら？
- 該当ファイルを手動で修正
- 修正が終わったら：
$ git add .
$ git rebase --continue
- 途中でやめたいとき：
$ git rebase --abort
🧼 PR前にやると何が嬉しい？
- ✅ mainの最新コードに追従することで衝突の予防
- ✅ PRの履歴が「自分の変更だけ」になり、レビューしやすい
- ✅ 意図しない差分が紛れ込むのを防げる
rebaseは共有前に使う！
-
git rebaseを使うと、コミットの履歴が書き換わります（見た目は同じでも、別のコミットとして扱われる） - そのため、すでに
pushしたブランチに対してrebaseすると、履歴のズレが発生し、他の人との整合が取れなくなります
「まだ他の人と共有していないブランチ」でだけ使うのが基本！
もしすでに GitHub に push していて、その後にrebaseを実行した場合は…
$ git push --force-with-lease
のように、**強制的に履歴を上書き（force push）**する必要があります。
🧱 なぜ危険なの？
- 他のメンバーがそのブランチを元に作業していると、履歴の不一致でマージやpullができなくなる
- 最悪の場合、他人の作業を上書きしてしまうリスクも
✅ 安全な運用ルール（おすすめ）
| 状況 | rebaseしてOK？ | 補足 |
|---|---|---|
| ローカル作業中だけのブランチ | ✅ 安全 | PR前にrebaseで履歴整理しよう |
| push済みだがまだ誰にも見せてない | ✅ 条件付き |
--force-with-lease で上書き可 |
| チームで共有中のブランチ | ❌ 原則NG |
mergeで済ませるのが安全 |
まとめ
| やりたいこと | コマンド例 |
|---|---|
| 作業ブランチを最新mainに追従 | git rebase origin/main |
| rebase途中で止める | git rebase --abort |
| rebase完了後、force pushが必要 | git push --force-with-lease |
「きれいな履歴を保ちつつ、最新のコードで安心してPRを出す」
それがgit rebase mainの最大のメリットです！