git squashとは？コミットが多すぎる履歴をまとめる手順とスカッシュマージの注意点

作業中に「タイポ修正」「レビュー指摘対応」「やっぱり戻す」といったコミットが積み上がり、プルリクエストを開いたら30件並んでいた、というのはよくある状況です。ここで決めるべきなのは、コミットを減らすかどうかよりも「どの単位で残すか」と「どの手段で畳むか」です。

この記事では、複数のコミットを1つにまとめる操作（git squash）の手順を、対象の範囲と作業の時点で選び分けられるように整理します。後半では、取り消し方、GitHub・GitLabのスカッシュマージ設定、スカッシュマージ後に派生ブランチが衝突する理由と直し方まで扱います。コマンドの出力例は、Git 2.50.1と、2026年9月28日公開のGit 2.56.0で実行して取ったものです。

まとめ

コミットが多すぎる履歴を整理する手段は、状況ごとに次のように決まります。

表のSHAは、まとめ先にするコミットの識別子です。実行時は対象コミットのSHAに置き換えます。

プルリクエストと切り戻しの単位が一致し、派生ブランチをほとんど使わないチームには、GitHubのマージ方式をスカッシュマージに固定する運用を勧めます。ただし、ブランチから別のブランチを切って重ねる運用をしているチームでは、スカッシュマージが派生ブランチの衝突を生みます。その場合は載せ替えの手順をセットで決めてください。

git squashとは：専用コマンドが無い「コミットをまとめる操作」の総称

「git squash」は、複数のコミットを1つのコミットにまとめる操作の通称です。squashという語が正式に出てくるのは、git-rebaseのドキュメントが定める対話的rebaseのアクション名（squash・fixup）と、git merge の –squash オプションです。git squash というサブコマンドは存在しません。

$ git squash
git: 'squash' is not a git command. See 'git --help'.

Git 2.54.0で追加された実験的コマンドの git history にも squash サブコマンドはありません（Git 2.56.0で git history squash を実行すると unknown subcommand で終了します）。同じ「1つにまとまった履歴」を作る経路は、対話的rebase、–fixup と –autosquash、git reset –soft、git merge –squash、そしてGitHub・GitLabのスカッシュマージです。

チームでsquashをどこまで使うかは、ブランチ戦略やマージ方式の取り決めの一部です。運用ルール全体の決め方はGit運用のベストプラクティス｜ブランチ戦略・命名規則・コミット規約とGitHubでの強制方法で扱っています。

コミットが多すぎる履歴の実害：bisectとrevertの精度低下

「履歴が汚い」は主観的な表現ですが、コミットが細かすぎて具体的に機能しなくなるものは2つあります。

1つは git bisect による原因特定です。bisectは各コミットが単体でビルド・動作することを前提に二分探索します。「途中まで書いたコミット」「後続とセットで初めて動くコミット」はビルドやテストが通らないため、git bisect skip で飛ばすことになります。飛ばしたコミットが原因の付近にあると、git-bisectのドキュメントが説明するとおり、最初に不具合を生んだコミットを一意に特定できなくなります。

もう1つは git revert による切り戻しです。対象が連続していれば git revert –no-commit <最古>^..<最新> で範囲ごと取り消せます（git-revertのドキュメントも「Sets of commits can also be given」と書いています）。問題になるのは、1つの機能の変更が他人の変更と交互に挟まって散らばっている場合で、取り消すコミットを手で拾い出すことになります。

逆に、bisectもrevertも使わない小規模なリポジトリでは、コミット数が多いこと自体の実害は小さく、整理の手間に見合うかは履歴を遡る運用があるかで決まります。

コミット粒度の基準：レビュー単位とrevert単位

「1PRあたり何件まで」と数で決めても機能しません。100行の設定変更と3,000行の機能追加では妥当な件数が違うためです。判断はコミットの中身で行います。

単体でレビュー・revertできる単位への分割とgit add -p

実用的な基準は、そのコミット単体でレビューでき、単体で取り消せるかです。この条件を満たすコミットは、後から見ても「何を、なぜ変えたか」が閉じています。

分けたときに効果が大きいのは、フォーマッタの一括適用を単独コミットにすることです。数千行の差分が出るため、ロジック変更と同じコミットに入れるとレビューできなくなります。作業を進めた後で分けたいときは、git add -p でファイル内の変更をハンク単位で選んでステージし、複数のコミットに切り出せます。

コミットそのものの考え方はコミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説で、メッセージを feat: fix: の接頭辞で統一する方法はConventional Commitsとは？書き方・type一覧とSemVer連携を実例で解説で扱っています。

畳む作業過程のコミットと残す判断のコミットの見分け方

畳む対象は、単体では意味を持たないコミットです。「typo修正」「レビュー指摘反映」「デバッグログ削除」「WIP」は、git showで差分を確認し、修正対象の本体コミットに吸収させます。

一方で、件数が増えても残すべきコミットがあります。最優先は障害対応で意図的に入れた暫定対処です。後から必ず「なぜその場しのぎを選んだのか」を問われるため、本体の修正と1つに畳むと判断の記録が消えます。依存ライブラリの版上げ、性能のために選んだ実装の切り替えも同様に単独で残します。

ローカルでコミットをまとめる手順

ローカルでまとめる手段は、まとめたい範囲と作業の時点で選びます。どの手段もコミットを作り直すため、SHAが変わります。

git rebase -iでsquash・fixupを指定する基本手順

直近のコミットを対話的に畳む基本形です。まとめたい範囲を HEAD~n で指定します。実行前に git status で未コミットの変更を確認し、必要ならコミットまたはstashして、退避用ブランチを作成してください。

$ git log --oneline -5
a1b2c3d typo修正
e4f5a6b レビュー指摘対応
0c7b349 デバッグログ削除
d1a90e1 ログイン機能を追加
4f2e8ab READMEを更新
$ git rebase -i HEAD~4

エディタが開いたら、残す1件を pick のままにし、吸収させるコミットを squash（s）か fixup（f）に書き換えます。todoリストは古い順に並び、上から順に適用されます。

pick d1a90e1 ログイン機能を追加
f 0c7b349 デバッグログ削除
f e4f5a6b レビュー指摘対応
f a1b2c3d typo修正

squashとfixupの違いはメッセージの扱いだけです。squashは畳んだ全コミットのメッセージを結合してエディタで編集させ、fixupは吸収される側のメッセージを捨ててまとめ先のメッセージをそのまま使います。「typo修正」のようにメッセージに残す価値が無いものはfixup、複数の意味ある変更を1件にまとめて説明を書き直したいときはsquashを使います。

連続していないコミットのsquash：todoリストの行の並べ替え

まとめたいコミットの間に別のコミットが挟まっている場合は、todoリストで行を移動してから fixup を指定します。次の例では、3件目の「fix a」を1件目の「feat a」の直下へ移しています。

pick 5a1c0e2 feat a
fixup 9d3b7f4 fix a
pick 3e8a6c1 feat b

保存すると、「feat a」と「fix a」が1件になり、「feat b」はその後ろに載り直ります。並べ替えた結果、間のコミットと同じ行を触っていればコンフリクトになるので、まとめ先と修正の間に同じファイルの変更が無いかを先に確認します。

–fixupと–autosquashによる修正先の指定と自動整列

todoリストを手で並べ替えるのは、件数が増えるほど間違えやすくなります。Gitには、まとめ先をコミット時点で宣言しておき、rebase時に自動で並べ替える仕組みがあります。

$ git add -p
$ git commit --fixup=d1a90e1
$ git log --oneline -2
9f8e7d6 fixup! ログイン機能を追加
a1b2c3d typo修正
$ git rebase --autosquash HEAD~5

コミットのタイトルに fixup! が自動で付き、rebase時にまとめ先の直下へ移動します。autosquashが認識する接頭辞は squash!、fixup!、amend! の3種です。Git 2.44.0のリリースノートに『”git rebase –autosquash” is now enabled for non-interactive rebase』とあるとおり、2.44以降は -i を付けずに実行できます。設定の rebase.autoSquash は対話的rebaseの既定を変えるだけで、-i を付けない実行には効きません。

メッセージも差し替えたい場合は、Git 2.32.0で入った –fixup=amend:<commit>（autosquash時にステージした変更を反映し、メッセージも差し替え）と –fixup=reword:<commit>（メッセージだけを置き換え）を使います。

git reset –softで直近n件を1コミットにまとめ直す

「直近の数件を丸ごと1件にしたい」だけなら、エディタを開かない git reset –soft が最短です。git-resetのドキュメントのとおり、–soft はインデックスと作業ツリーに触れずにHEADだけを戻すので、戻した範囲の変更がステージされた状態で残ります。

$ git log --oneline
c5e0a91 c5
7d21b3f c4
0a9f6e2 c3
c51bf1d c2
8b00558 c1
$ git reset --soft HEAD~3
$ git commit -m "c3〜c5をまとめる"
$ git log --oneline
989bde5 c3〜c5をまとめる
c51bf1d c2
8b00558 c1

この方法は途中のコミットを選べず、戻した範囲のメッセージもすべて捨てます。–soft を –hard と打ち間違えると、コミットしていない変更ごと消えます。初期コミットまで含めて畳みたいときは、HEAD~n では数えられないので git rebase -i –root を使い、先頭行を pick、2行目以降を fixup にします。

git merge –squashによる作業ブランチ全体の1件化

個々のコミットを選ばず、作業ブランチの成果をまとめて1コミットにする手段です。

$ git switch main
$ git merge --squash feature/login
Squash commit -- not updating HEAD
$ git commit -m "ログイン機能を追加"

merge –squash は変更を作業ツリーとインデックスに反映するだけで、コミットもマージ記録も作りません。そのため main から見ると feature/login のコミットは取り込まれていない扱いになります。git branch -d はupstreamが設定されていればupstreamへの取り込みで、未設定ならHEADへの取り込みで判定するので、upstream未設定のまま main 上で git branch -d feature/login を実行すると「not fully merged」で失敗します。取り込み漏れが無いことを確かめてから -D で削除します。

Git 2.54以降の実験的コマンドgit historyのfixup・reword・drop

Git 2.54.0（2026年4月20日）で、rebaseを使わずに履歴を書き換える実験的コマンド git history が入りました。squash サブコマンドは無く、まとめる用途に近いのは2.55.0（2026年6月29日）で加わった fixup です。git-historyのドキュメントは fixup を「git commit –fixup=<commit> の後に git rebase –autosquash <commit>~ を実行するのに近い」と説明しています。

$ git log --oneline --all --decorate
36c4c72 (feature/part2) セッション管理を追加
a31de9d (HEAD -> feature/part3) ログアウトを追加
3ff9e58 (main) ログイン機能を追加
$ echo 2 >> login.py
$ git add login.py
$ git history fixup main
$ git log --oneline --all --decorate
8c85884 (feature/part2) セッション管理を追加
9a5a64d (HEAD -> feature/part3) ログアウトを追加
7a4735a (main) ログイン機能を追加

ステージした変更が「ログイン機能を追加」に入り、main を含む3本のブランチがすべて書き換わりました。既定の –update-refs=branches が、書き換えたコミットとその子孫を指すローカルブランチを更新するためで、push済みのコミットに向けて実行してはいけません。競合が起きる操作は「error: fixup would produce conflicts; aborting」で中止し、マージを含む履歴も扱えません。ドキュメントに「THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.」とあるため、チームの手順書には rebase -i と –autosquash を残すのが妥当です。

squashの取り消し：ORIG_HEADとreflogで元の履歴に戻す

畳んだ後で「やはり分けておきたかった」と気づいても、元のコミットはすぐには消えません。戻し方は時点で変わります。

• rebaseの途中：git rebase –abort で開始前の状態に戻ります。
• 畳んだ直後：git reset –hard ORIG_HEAD で戻ります。
• しばらく経った後：git reflog で畳む前のSHAを探し、git reset –hard <SHA> で戻ります。

ORIG_HEAD は、resetやrebaseがHEADを動かす前の先端を記録する参照です。git reset –soft で畳んでコミットした後でも、ORIG_HEAD は reset 前の先端を指したままでした。

$ git reset --soft HEAD~2
$ git commit -m squashed
$ git log --oneline
b7b2249 squashed
7e6aa9a c1
$ git reset --hard ORIG_HEAD
HEAD is now at 0fa8d88 c3
$ git log --oneline
0fa8d88 c3
f63cac7 c2
7e6aa9a c1

ただし、ORIG_HEAD はresetやrebaseを実行するたびに上書きされます。git-rebaseのドキュメントも、rebase中にresetなどを実行すると終了時に同じコミットを指す保証は無いと書いています。2回以上操作した後は reflog で探すほうが確実です。

reflogにも期限があります。git-gcのドキュメントによると、現在の先端から到達できるエントリは gc.reflogExpire の既定90日、到達できないエントリは gc.reflogExpireUnreachable の既定30日で期限切れになります。squashやamendで置き換えられた古いコミットのreflogエントリには、通常この30日の設定が適用されます。ただし、30日は復旧保証期間ではなく、エントリの経過時間や設定、期限切れ処理とオブジェクト削除の実行状況で復旧可能性は変わります。重要な作業の前は、git branch backup/login のように退避用のブランチを1本切っておけば期限を気にせずに済みます。なお、git reset –hard はコミットしていない変更も消すので、実行前に git status で作業ツリーが空であることを確かめてください。

rebaseそのものの仕組みややり直しの全体像はgit rebaseとは？使い方・mergeとの違い・コンフリクト解決とやり直しを解説、マージの取り消しはgit mergeの取り消し｜abort・reset・revert -mの使い分けで扱っています。

GitHub・GitLabのスカッシュマージ設定

「レビュー前にsquashしてください」という依頼だけでは実施を強制できません。履歴をプルリクエスト単位に統一するなら、許可するマージ方式をリポジトリ設定で制限できます。マージ時に必ず1コミットに畳まれる設定にしておけば、作業ブランチが散らかっていても main の履歴はプルリクエスト単位に揃います。

GitHubのSquash and merge設定と既定コミットメッセージ

GitHubでは、リポジトリの Settings > General > Pull Requests でマージ方式を選びます。Allow squash merging だけを残し、他のチェックを外せば、マージボタンはスカッシュだけになります。

同じ画面で、スカッシュ時の既定メッセージも選べます。GitHubのドキュメントによると、既定はコミットが1件ならそのタイトルと本文、2件以上ならプルリクエストのタイトルとコミット一覧です。ほかに、プルリクエストのタイトルのみ、タイトルとコミットの詳細、タイトルと説明の3形式があります。既定のままだと散らかったコミット一覧がそのまま本文に入るので、「プルリクエストのタイトルと説明」を選ぶことを勧めます。

リポジトリ設定は管理者が変えられるため、組織として強制したい場合はブランチのrulesetを使います。rulesetのルール一覧では、プルリクエスト必須のルールで許可するマージ方式（merge・squash・rebase）を絞れます。Require linear history はマージコミットのpushを禁じ、プルリクエストの取り込みをsquashかrebaseに限ります。rulesetが要求する方式をリポジトリ設定で無効にしているとマージがブロックされるので、両方を揃えてください。プルリクエストの作成からマージ方式の選び方まではGitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方にまとめています。

gh pr merge –squashによるターミナルからのスカッシュマージ

ブラウザを開かずに畳むなら、GitHub CLIの gh pr merge を使います。gh pr mergeのマニュアルのとおり、-s（–squash）でスカッシュマージし、-t（–subject）と -b（–body）でメッセージを指定できます。

$ gh pr merge 128 --squash --delete-branch \
    --subject "ログイン機能を追加 (#128)" \
    --body "パスワード認証とセッション管理を追加"

必須チェックが通る前に –auto を付けると、条件を満たした時点で自動マージする予約になります。ghの導入はghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.102対応】を参照してください。

GitLabのSquash commits when merging：4つの選択肢

GitLabでは、プロジェクトのマージリクエスト設定にある Squash commits when merging で挙動を決めます。GitLabのドキュメントによると選択肢は4つです。

スカッシュを必須にする設定は Require です。ただし、GitLabではMerge methodが別設定で、Merge commitを選ぶとスカッシュ後にもマージコミットが追加されます。取り込みを1コミットにするにはFast-forward mergeと組み合わせます。移行期間は Encourage にしておき、例外を個別に外せるようにする手もあります。

スカッシュマージのデメリット：派生ブランチの衝突とrebase –ontoでの直し方

スカッシュマージは、ブランチのコミットとは親子関係の無い新しい1コミットを main に作ります。GitHubのマージ方式の解説にあるとおり、元のコミットは main の履歴に入りません。これが問題になるのは、feature/a からさらに feature/b を切って作業を重ねている場合です。

feature/a（コミットA1・A2）をスカッシュマージした後、feature/b を main に載せ直すと、Gitは feature/b に含まれる A1・A2 を「まだ main に無い変更」として適用しようとし、スカッシュされた同じ変更とぶつかります。

$ git switch main
$ git merge --squash feature/a
$ git commit -m "A (#1)"
$ git switch feature/b
$ git rebase main
Rebasing (1/3)Auto-merging a.py
CONFLICT (content): Merge conflict in a.py
error: could not apply 1861cfc... A1

feature/a が1コミットだけなら、パッチが同一なので「skipped previously applied commit」で通ることがあります。2コミット以上を畳むとパッチ単位の一致では除外できなくなり、この例のように畳んだ変更と feature/b の変更が同じ行に触れていると衝突します。別ファイルの追加だけなら、適用結果が空になって自動で除外され、衝突しないこともあります。この例では、main を feature/b へマージする方法でも同じ箇所でコンフリクトが起きました。

直し方は、feature/a の旧先端より後ろにある feature/b 固有のコミットだけを main に載せ替えることです。

$ git rebase --abort
$ git rebase --onto main feature/a feature/b
Successfully rebased and updated refs/heads/feature/b.
$ git log --oneline --graph main feature/b
* b33376d B
* da15c14 A (#1)
* 969a038 init

git rebase –onto <新しい土台> <除外する範囲の終点> <ブランチ> は、「終点より後ろのコミットだけを新しい土台に載せる」指定です。終点にはスカッシュ前の feature/a の先端を渡します。マージ後にブランチを消してしまった場合は、プルリクエストの Commits タブで最後のコミットのSHAを確認するか、reflog から探して SHA で指定します。

GitHub側は、マージ後に head ブランチを削除すると、そのブランチをベースにしていた同じリポジトリのオープンなプルリクエストのベースを、マージ先のブランチへ自動で付け替えます（プルリクエストのマージ手順）。ただし付け替わるのはベースだけで、派生ブランチに残った A1・A2 は消えないため、手元での –onto による載せ替えは必要です。

マージ前に重ねたブランチをまとめて main に追従させたいときは、Git 2.38.0で入った git rebase –update-refs が使えます。先端のブランチで実行すると、書き換え対象のコミットを指す途中のブランチの参照も更新されます。ただし、別のworktreeでチェックアウト中のブランチは更新されません。コンフリクトの仕組みと解消の基本はコンフリクトとは？Gitで変更が衝突する仕組みと解消手順・予防設計を実装視点で解説で扱っています。

push済みのコミットをsquashするときの安全策

コミットを畳む操作は履歴の書き換えです。git-rebaseのドキュメントも、他人が作業の土台にしているブランチのrebaseには問題があると警告しています。

書き換えてはいけない共有ブランチの条件

rebaseもsquashもしないのは、レビュアーが手元にチェックアウトしているブランチ、別の作業ブランチの分岐元になっているブランチ、CIやデプロイが特定のSHAを参照しているブランチです。書き換えると、相手の手元の履歴とリモートが食い違い、次のpushやpullで衝突します。前章の派生ブランチの衝突もこの一種です。

自分専用の作業ブランチでsquashしてforce pushする手順

push済みでも、自分しか使っていない作業ブランチなら畳んで構いません。プルリクエストを開く前に履歴を整える場面がこれに当たります。

$ git fetch origin
$ git switch feature/login
$ git rebase -i origin/main
  （todoリストでまとめる行を fixup に書き換えて保存）
$ git log --oneline origin/main..HEAD
$ git push --force-with-lease --force-if-includes origin feature/login

git log origin/main..HEAD で、main に無い自分のコミットが意図した件数になっているかを確かめてからpushします。レビューが始まっているプルリクエストでは、畳む前にレビュアーへ一言伝えてください。レビュアーが手元にチェックアウトしていれば、その時点で共有ブランチの扱いになります。

git push -f をそのまま使うと、自分のfetch以降に他人が積んだコミットを黙って消します。–force-with-lease はリモート追跡refが期待どおりのときだけ上書きしますが、Git 2.30.0のリリースノートは『”git push –force-with-lease[=<ref>]” can easily be misused to lose commits unless the user takes good care of their own “git fetch”.』と書いています。エディタの自動fetchなどで追跡refだけが更新されると、他人のコミットを見ていないのにチェックを通ってしまうためです。

この穴を塞ぐのが、同じ2.30.0で入った –force-if-includes です。git-pushのドキュメントによると、リモート追跡refの先端がローカルブランチのreflogから到達できるかを検証し、取り込んでいない更新があればpushを拒否します。–force-with-lease を付けずに単独で渡すと何もしない点に注意してください。

GitHubでのコミット履歴とコミットIDの確認方法

ブランチ全体の履歴は、ファイル一覧右上のコミット件数のリンク、またはURL末尾を /commits/<ブランチ名> にすると開きます。特定ファイルの変更履歴は、ファイルを開いて History を選びます。

各コミットの右に出る7桁の英数字が、コミットID（SHA-1ハッシュ）の短縮形です。完全な値は40桁で、コミット画面のコピーボタンで取得できます。git rebase -i や –fixup= には短縮形のままで渡せます。2つのブランチの差分は、URL末尾を /compare/<base>…<head> にすると、共通の祖先から head までの変更が並びます。

手元で分岐を図で確かめたい場合は、Git Graphの使い方｜VS Codeでコミット履歴・ブランチを可視化する拡張機能と見方で紹介している拡張機能を使うと、rebase前後の形の変化を追えます。よく使うコマンドの全体像はGitコマンド一覧｜用途別早見表とよく使う基本コマンドの使い方を解説にまとめています。

受託開発での判断：squashを標準にする条件と履歴を残すリポジトリ

受託開発のリポジトリでマージ方式を選ぶ際は、切り戻し単位と派生ブランチの有無を判断基準にすることを提案します。

スカッシュマージを標準にするのは、3条件がそろうリポジトリです。プルリクエストが1機能・1修正の単位で切られていること、切り戻しの単位がプルリクエストと一致していること、ブランチから別のブランチを切って重ねる運用がほとんど無いことです。この3つがそろえば、main の1コミットがそのまま「1つのrevert単位」になります。各コミットでテストできればbisectで原因のプルリクエストを特定しやすくなりますが、その内部の変更をコミット単位で絞ることはできなくなります。

反対に、スカッシュを標準にしないのは2種類のリポジトリです。1つは、1本のプルリクエストが数週間生きる大型ブランチを抱えるもので、途中の設計判断が数十コミットに分かれて記録されており、1件に潰すと「なぜこの実装にしたか」を後から追えなくなります。もう1つは、立ち上げ期で派生ブランチが日常的に作られるもので、前章の衝突が毎週のように起きます。どちらも Create a merge commit を使い、ローカルでの fixup 整理だけを求めます。

マージ方式は、ブランチ保護・必須チェック・自動デプロイとセットで決めないと途中で崩れます。CIの必須チェックを通ったプルリクエストだけをスカッシュマージで入れ、main への到着をデプロイの起点にする設計まで含めて相談したい場合は、DevOps・CI/CD導入支援で対応しています。Git本体の現行版と更新手順はGitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点【2026年10月】で確認できます。

よくある質問

コミットは何件までにまとめるのが正解ですか？

件数の正解はありません。基準は、コミット単体でレビューでき、単体でrevertできるかです。3,000行の機能追加なら10件でも妥当で、設定ファイル1行の変更が3件に分かれていれば多すぎます。

Gitのrebaseは危険ですか？

危険なのは、他人が参照している共有ブランチを書き換えたときです。自分専用のブランチなら、途中で git rebase –abort、直後なら git reset –hard ORIG_HEAD、後日なら reflog から元に戻せます。置き換えられた古いコミットは既定で30日を過ぎると消える可能性があるので、大きな整理の前は退避用のブランチを切っておくと安全です。

rebase中にコンフリクトが起きた場合はどうしますか？

該当ファイルを直して git add した後、git rebase –continue で次へ進みます。そのコミットの適用自体が不要なら git rebase –skip で飛ばせます。判断がつかない場合は git rebase –abort で開始前に戻してから考え直します。

–fixupで指定するSHAが分からない場合はどうしますか？

git log –oneline で対象コミットの短縮SHAを確認して指定します。修正が特定のファイルに閉じているなら、git log –oneline — <ファイルパス> で候補を絞り込めます。

GitHubでスカッシュマージした後、ローカルのブランチはどう扱いますか？

そのブランチで作業を続けず、最新の main から新しいブランチを切り直します。元のコミットは main の祖先に入らないため、upstream未設定のまま main 上で git branch -d を実行すると削除は拒否されます。git log main..<ブランチ名> で残ったコミットがプルリクエストに含めたものだけだと確かめてから、git branch -D で消してください。そのブランチから派生した別のブランチがあれば、本文の git rebase –onto で載せ替えます。

関連記事

• git rebaseとは？使い方・mergeとの違い・コンフリクト解決とやり直しを解説
• コミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説
• GitHubのPull Requestの作り方：作成手順とマージ方式・レビュー必須化の決め方
• コンフリクトとは？Gitで変更が衝突する仕組みと解消手順・予防設計を実装視点で解説
• git mergeの取り消し｜abort・reset・revert -mの使い分け