Rebaseを“怖くなく”使いこなす：GUI先行＋最小CLIで理解する（2025年版技術ブログ）

2025年9月3日

1. TL;DR
2. 1. rebase を一言で
- 2.1. 図で理解
- 2.2. 注意
3. 2. merge と rebase の違い（いつどっち？）
4. 3. 安全ルール（ここだけは守る）
5. 4. まずは GUI で試す（推奨手順）
- 5.1. 4-1. GitHub Desktop
- 5.2. 4-2. Visual Studio（VS 2022 以降）
6. 5. CLI の最小手順（“読む・戻す”込み）
- 6.1. 5-1. 基本の rebase
- 6.2. 5-2. 読む・戻すの保険（復旧の技）
7. 6. 練習シナリオ（5分×2）
- 7.1. シナリオA：自分の feature を最新 main に追従（GUI版）
- 7.2. シナリオB：rebase をやり直す（CLI版）
8. 7. よくある落とし穴と回避
9. 8. 現場導入チェックリスト
10. 9. まとめ

TL;DR

rebase = 自分の作業の土台を最新に差し替え、コミットを“並べ替えて再生”する操作。
使いどころ：ローカルの feature ブランチをレビュー前に最新 main に追従させ、PRの差分をスッキリ見せたいとき。
やってはいけない：共有済みブランチ（他人がpullしている）を勝手にrebaseして push。必要ならチーム合意＋–force-with-lease。
実務の型：普段は GUI（Visual Studio / GitHub Desktop）、復旧と高度操作は 最小限CLI。

1. rebase を一言で

「自分のコミットを作り直して、最新 main の“上”に並べ直す」こと。

内容は同じでもコミット ID（ハッシュ）は変わる＝履歴を書き換える。

図で理解

# rebase 前（Bで分岐し、その後 main が進んでいる）
A---B---C---D   (main)
     \
      d---e     (feature)

# rebase 後（feature を最新 main=D の上に載せ替え）
A---B---C---D   (main)
                \
                 d'--e'  (feature)

d, e は d’, e’ として 作り直される（ハッシュが変わる）。
その後、main に fast-forward で取り込むと履歴が一直線になり、レビューが読みやすい。

# fast-forward で取り込んだ後
A---B---C---D---d'---e'   (main = feature)

注意

すでに共有（push）した履歴を rebase すると他メンバーに影響します。必要な場合は合意の上で行い、更新時は –force-with-lease を使いましょう。

2. merge と rebase の違い（いつどっち？）

merge：枝分かれをそのまま残し、マージコミットで接続（合流の事実を履歴に残したいとき）
rebase：自分のコミットを作り直し、直線履歴に（PR差分を小さく、読みやすくしたいとき）

判断基準

PRをスッキリ・CIを通しやすく → rebase
履歴改変を避けたい・合流点を明示したい → merge

3. 安全ルール（ここだけは守る）

rebase は“自分のローカル feature”で（共有ブランチにしない）
共有に出した後でrebaseする場合は必ず合意を取り、git push –force-with-lease を使う
ブランチ保護（PR必須・直push禁止・CI必須）を main/dev に設定しておく
競合解消はGUIのマージエディタで落ち着いて（“正しさ＞スピード”）

4. まずは GUI で試す（推奨手順）

4-1. GitHub Desktop

feature/xxx にチェックアウト
メニュー Branch → Rebase current branch… → 基準に main を選び実行
競合が出たら Desktop が一覧を表示 → VS / 好みのエディタで解消 → 保存 → Desktop で続行
完了後、Force push を求められたら実行（–force-with-lease 相当）

メモ：Update from main は「マージ更新」。直線履歴にしたいときは Rebase current branch… を使う。

4-2. Visual Studio（VS 2022 以降）

Pull を常に rebase にしたい：Git 設定 → Rebase local branch when pulling を有効化（リポ単位/グローバル）
手動で：Git メニューのブランチ操作から Rebase を選択
競合は Merge Editor（3ペイン） で解消 → 保存 → 続行

5. CLI の最小手順（“読む・戻す”込み）

5-1. 基本の rebase

# 最新を取得
git fetch origin

# 作業ブランチへ
git switch feature/add-login

# 最新 main の上に並べ替える
git rebase origin/main

競合が出たら

# 競合ファイルを編集して解決 → ステージ
git add <conflicted-files>

# 続行
git rebase --continue

# どうしてもやめたい
git rebase --abort

共有へ反映（履歴を書き換えたので“慎重に”）

git push --force-with-lease

5-2. 読む・戻すの保険（復旧の技）

# 状態を読む
git status
git log --oneline --graph --decorate --all

# “救命索”：HEADの移動履歴（やり直しの起点探し）
git reflog

# 未コミットの変更を捨てる（ワークツリーを戻す）
git restore .

# どうしても巻き戻す（破壊的・要注意）
git reset --hard <hash>

ポイント：rebaseに失敗しても reflog が最後の拠り所。焦らず「良かった状態」のハッシュに戻せます。

6. 練習シナリオ（5分×2）

シナリオA：自分の feature を最新 main に追従（GUI版）

feature/ui-tweak に切替
Rebase current branch… → main
競合が出たら VS の Merge Editor で解消 → 保存 → 続行
テスト → Force push → PR 更新（差分がスリムになっていることを確認）

シナリオB：rebase をやり直す（CLI版）

git rebase origin/main 実行中に不安になったら → git rebase –abort
状態を読む：git status、git log –oneline –graph
もう一度、競合ファイルを少しずつ直して git rebase –continue
失敗で壊れた気がしたら git reflog → git reset –hard <良い時点> で復旧

7. よくある落とし穴と回避

他人が使っている共有ブランチをrebase→ 原則禁止。必要時は合意を取り、–force-with-lease で安全に。
競合が多すぎてパニック→ 1ファイルずつ、「Current / Incoming / Result」 をGUIで確認。ビルド・テストのサイクルを短く。
pull 方針がメンバーでバラバラ→ VS設定 or チーム規約で pull –rebase を統一。
main で reset –hard→ 共有履歴を破壊するためNG。個人ブランチでのみ行う。