タイポ修正でコミット履歴を汚さない！Gitの「fixup」と「autosquash」でスマートに履歴を整える実践技

2026/08/29

開閉

「プルリクを出したら、コミット履歴が『WIP』『タイポ修正』『修正その2』で埋め尽くされている……」

20代の頃、機能開発に夢中になるあまり細かな修正コミットを乱立させてしまい、先輩エンジニアから「レビューしやすいようにコミット履歴は綺麗にまとめようね」と優しく指摘されて恥ずかしい思いをしたことがあります。

慌てて git rebase -i を実行したものの、エディタ上でコミットの順番を入れ替える最中にコンフリクトを起こして頭を抱える……というのも、エンジニアあるあるではないでしょうか。

今回は、開発中に発生したタイポや微修正を、過去の該当コミットへ全自動で統合してくれるGitの隠れた名機能 git commit --fixup と git rebase -i --autosquash の実践的な使い方をご紹介します。これを知ってから、私のプルリク作成時の心理的ハードルは劇的に下がりました。

検証環境と使用ツール

本記事で解説する機能と動作確認環境は以下の通りです。

Git: 2.38+（Git for Windows / macOS / Linux）
コミット機能: git commit --fixup（Git 公式ドキュメント: git-commit）
リベース機能: git rebase -i --autosquash（Git 公式ドキュメント: git-rebase）
グローバル設定: rebase.autoSquash（Git 公式ドキュメント: git-config）

※--fixup や rebase.autoSquash 自体は Git 1.7.4 以降の初期から存在する枯れた機能ですが、近年の Git（2.x系）ではより安定して高速に動作します。

なぜ普通の `git rebase -i` だけでは面倒なのか？

従来、コミット履歴を整理するには git rebase -i HEAD~5 などのインタラクティブ・リベースを実行し、エディタ上でコミットの順番を上下に入れ替えたり、pick を squash や fixup に手動で書き換えたりする必要がありました。

この作業は、対象のコミット数が多いと「どのハッシュ値に統合すべきか」を探すのが大変で、コンフリクトの原因にもなりがちでした。

--fixup オプションを使えば、「どのコミットに対する修正か」をコマンド実行時に指定するだけで、Gitが再配置と統合の指示書を全自動で組み立ててくれます。

処理の流れ比較

graph TD
    A["開発中にタイポや微修正を発見"] --> B["git commit --fixup (対象コミットハッシュ) を実行"]
    B --> C["Gitが fixup! コミットを自動作成"]
    C --> D["キリの良いタイミングで git rebase -i --autosquash を実行"]
    D --> E["Gitが修正コミットを過去の対象コミットの直下へ自動移動＆統合"]
    E --> F["無駄な修正コミットが消え、美しい1つのコミットに合体完了"]

実践ステップ：`--fixup` と `--autosquash` の使い方

具体的なシナリオに沿って、コマンドの実行手順を見ていきましょう。

シナリオ：過去の機能実装コミットにタイポが見つかった場合

まず、git log --oneline で現在のコミット履歴を確認します。

a1b2c3d (HEAD -> feature/user-auth) Add user authentication logic
f9e8d7c Add login form component
1a2b3c4 Initial commit

トップの a1b2c3d ("Add user authentication logic") のコードにタイポがあることに気づいたとします。

1. 修正ファイルをステージングし、`--fixup` 付きでコミット

修正箇所のコミットハッシュ（ここでは a1b2c3d）を指定してコミットします。

git add src/auth.js
git commit --fixup a1b2c3d

このコマンドを実行すると、Gitは以下のような特別なコミットメッセージを自動生成します。

e5f6g7h (HEAD -> feature/user-auth) fixup! Add user authentication logic
a1b2c3d Add user authentication logic
f9e8d7c Add login form component

2. `--autosquash` 付きで rebase を実行

修正作業が区切りを迎えたら、以下のコマンドを実行します。

git rebase -i --autosquash f9e8d7c~1

コマンドを実行すると設定されたエディタが開き、すでに以下のように fixup の並び替えと指示コマンドが自動配置 されています。

pick a1b2c3d Add user authentication logic
fixup e5f6g7h fixup! Add user authentication logic

# Rebase f9e8d7c..e5f6g7h onto f9e8d7c

ユーザーは何も行を入れ替える必要はありません。エディタをそのまま保存して閉じる（:wq や VS Codeのタブ閉じ）だけで、リベースが自動で実行されます。

ターミナルには以下のように統合完了のログが出力されます。

Successfully rebased and updated refs/heads/feature/user-auth.

git log --oneline を再度確認してみましょう。

a1b2c3d (HEAD -> feature/user-auth) Add user authentication logic
f9e8d7c Add login form component
1a2b3c4 Initial commit

fixup! コミットが見事に消え去り、元のコミット（a1b2c3d）へ綺麗にタイポ修正の差分が統合されていることが確認できます。

日常の作業を効率化する Git 設定とエイリアス

毎回 --autosquash をタイピングするのは手間です。.gitconfig に設定を追加し、git rebase -i 実行時に常に --autosquash が有効化されるようにしておきましょう。

[rebase]
    # rebase -i 実行時に常に autosquash を有効化
    autoSquash = true
[alias]
    # git fixup <commit-hash> で実行できるようにエイリアス設定
    fixup = commit --fixup

この設定を追加しておけば、以下の2ステップだけでコミット整理が完結します。

# 修正の作成（直前のコミットなら HEAD でも可）
git fixup a1b2c3d

# 自動統合の実行（分岐元ブランチを指定）
git rebase -i origin/main

現場でハマりやすい注意点とOS差異

実務でリベースを活用する際、つまずきやすいポイントがいくつかあります。

1. PowerShell環境におけるキャレット（`^`）の扱い

macOSやLinuxのシェル（bash / zsh）では、親コミットを指定する際に HEAD^ や <hash>^ と書くのが一般的です。しかし、WindowsのPowerShell環境では ^ がエスケープ文字等として解釈されるケースがあり、構文エラーや意図しないコミットの指定につながることがあります。

Windows環境（PowerShell）で作業する際は、"f9e8d7c^" のようにダブルクォートで囲むか、より安全にチルダ記号を使って f9e8d7c~1 や HEAD~1 と指定するか、あるいは origin/main のようにブランチ名を起点にリベースすることを推奨します。

2. 対話エディタ（Vim）の操作に戸惑う場合

git rebase -i を実行すると、コミット指示書を編集するためにターミナル上でエディタが起動します。初期設定のままだとVimが立ち上がるため、操作方法を知らないと「ターミナルが固まって抜け出せない」という状態に陥りがちです。

VS Codeを常用している場合は、以下の設定を行っておくと便利です。

git config --global core.editor "code --wait"

これにより、リベース実行時にVS Codeの新規タブとして指示書が開き、確認後に保存してタブを閉じる（Ctrl+W / Cmd+W）だけで処理を続行できます。

3. すでにPushした共有ブランチではリベースしない

git rebase は既存のコミットハッシュを再計算して新しいコミットへと置き換える「歴史改変」操作です。

ローカル環境での作業中や、自分だけが作業しているフィーチャーブランチ（PR作成前）であれば何回実行しても安全です。しかし、チームメンバーが共同で作業している共有ブランチや、すでにマージ済みのコミットに対してリベースを行い、強制プッシュ（git push --force）することは絶対に避けてください。チーム全体のGit履歴に不整合が生じ、重大なトラブルの原因となります。「整えるのは手元のローカル履歴のみ」という原則を守りましょう。

導入して実感したチーム開発への貢献

レビューアの負担を大幅に軽減できる PRのコミット履歴が「機能追加」「テスト追加」のように意味のある単位で整然と並ぶため、レビューアが意図を理解しやすくなり、マージまでの速度が向上しました。
git bisect によるバグ特定の精度向上 後日バグが発生した際に git bisect で過去のコミットを遡る際、壊れた中途半端な WIP コミットが存在しないため、原因特定がスムーズになりました。
無駄なストレスからの解放 開発中に「あ、ここも直さなきゃ」と思った時に、無理に git commit --amend で作業を中断されることなく、テンポよく作業を進められるようになりました。