Gitの基本操作やチームでの運用には慣れてきたけど、 「履歴をきれいに整える方法」まではあまり手をつけていない──そんな方に向けた記事です。 本記事では、rebase・amend・stashという3つの履歴操作コマンドに絞って、 どんなときに使うのか、どう使うべきかを実践的に解説します。 チームにとって読みやすく、意味のある履歴を残すために、 あとから履歴を整えるテクニックを身につけましょう。
なぜ「履歴を整える」ことが重要なのか？
Gitの履歴は、ただの作業記録ではありません。 「なぜこの変更をしたのか」「どのように進めたのか」をチームに伝えるための重要な情報源です。
履歴が整っていないと──
- 意図の見えないコミットが並び、PRレビューに時間がかかる
- 「何をやったのか」が把握できず、後からバグを追うのが困難になる
- チーム内での学びや共有が生まれにくくなる
逆に、履歴が整っていると、以下のようなメリットがあります：
- 一目で流れがわかり、PRの意図が伝わりやすくなる
- 履歴をたどるだけで、誰が・なぜ・どのように修正したかが明確になる
- チームのナレッジとしても資産化できる
💡 “Gitは単にコードを保管しておくデータベースではなく、コミュニケーションツール”とも言われます。
だからこそ、後からでも履歴を整える技法は知っておくべきなのです。
▶︎ git rebase 「履歴を置き換える」
【使う場面】
- コミット履歴をまとめたい
- PR前に、履歴を整理して読みやすくしたい
- 履歴を直線状に整えたい（マージコミットを避けたい）
rebase は、過去のコミット履歴を後から並べ替えたり、統合したりする強力なコマンドです。 特にチームにレビューを依頼する前に、「このPRで何をしたか」が伝わるような綺麗な履歴に整える場面で活躍します。
【使い方】
git rebase -i HEAD~3 # 最近の3コミットを対象に履歴を編集
実行するとエディタが開き、コミットごとの操作指示を下記から選べます。編集後、指示に従ってメッセージを修正・確定すれば完了です。
pick（そのまま）reword（メッセージだけ変更）squash（前のコミットと統合）drop（コミットを削除）
【実例】
実際にいくつかcommitをしてみてrebaseコマンドを使って履歴を編集してみます。rebaseコマンドを時効すると下記のようなファイルが開きます。試しに編集してファイルを閉じてみます。
pick 2400efa 2回目のcommit
pick ffe0d9b 3回目のcommit
pick fadce32 4回目のcommit
pick 53d46bb 5回目のcommit
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓編集してみる
pick 2400efa 2回目のcommit
pick ffe0d9b 3回目のcommit
squash fadce32 4回目のcommit #3回目のcommitと統合される
drop 53d46bb 5回目のcommit #消える上記のファイルの編集が終わると、次にcommitメッセージをどのようにするか編集するファイルが開きます。
# This is a combination of 3 commits.
# This is the 1st commit message:
3回目のcommit
# This is the commit message #2:
4回目のcommit
# This is the commit message #3:
4回目のcommit
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓編集してみる
# This is a combination of 3 commits.
# This is the 1st commit message:
3回目のcommit
# This is the commit message #2:
２回目のcommit（再編集）
# This is the commit message #3:
３回目のcommit（再編集）これでrebaseの作業は完了しました。コマンドライン上は下記のようになっており、最後にコミット履歴が統合、削除されているのがわかります。この例では編集されたファイルを載せませんが、削除されたcommitはファイルの内容もそのcommit分だけ消えています。
# コミット履歴の確認
git-sample % git log --oneline
53d46bb (HEAD -> main) 5回目のcommit
fadce32 4回目のcommit
ffe0d9b 3回目のcommit
2400efa 2回目のcommit
eb84fe0 1回目のcommit
# HEAD含め、４回分のcommit履歴を取得
% git rebase -i HEAD~4
# コミット履歴の確認
git log --oneline
adaf5d2 (HEAD -> main) 3回目のcommit
2400efa 2回目のcommit
eb84fe0 1回目のcommit
# コミット履歴の確認（詳細確認）
git-sample % git log
commit adaf5d2011da58434e0503ac5f9f56f853170f99 (HEAD -> main)
Author: tamotech <86551907+tamotech1028@users.noreply.github.com>
Date: Wed May 28 12:49:22 2025 +0900
3回目のcommit
２回目のcommit（再編集）
３回目のcommit（再編集）
commit 2400efac8959af74c7b99a506de50de5a2091193
Author: tamotech <86551907+tamotech1028@users.noreply.github.com>
Date: Wed May 28 12:48:46 2025 +0900
2回目のcommit
commit eb84fe03467f0eb1863505cee1a71efac5a99cfe
Author: tamotech <86551907+tamotech1028@users.noreply.github.com>
Date: Wed May 28 12:48:16 2025 +0900
1回目のcommit⚠️ 他人と共有済みのブランチの履歴を
rebaseすると、履歴の書き換えが原因でコンフリクトが発生したり、チームの作業に支障をきたすことがあります。共有前のタイミングで行うのが鉄則です。
⚠️
rebase -iではコミットの順番を自由に並べ替えることができますが、前のコミットに依存している処理が後に来ると、適用時にエラーやコンフリクトが発生する可能性があります。たとえば、先に定義したクラスや関数に依存した変更を前に持ってくると、その時点では未定義となり rebase に失敗します。順番を変えるときは、依存関係を必ず意識しましょう。
▶︎ git commit --amend 「直前のコミットを修正」
【使う場面】
- コミットメッセージを誤った
- 追加し忘れたファイルや変更を反映したい
- 小さな修正を前のコミットにまとめたい（履歴をきれいに保つため）
【使い方】
git add . # 修正・追加したいファイルをステージング
git commit --amend # 直前のコミットと統合（メッセージも編集可能）
- コマンドを実行すると、エディタが立ち上がり、前回のコミットメッセージを修正できます。
- ファイル変更がある場合、それも前のコミットに取り込まれます。
【実例】
実際に–amendで直前のコミットと結合してみます。git commit –amendを実行するとコミットメッセージの編集が可能です。
# 現在のcommit履歴を確認
git-sample % git log --oneline
adaf5d2 (HEAD -> main) 3回目のcommit
2400efa 2回目のcommit
eb84fe0 1回目のcommit
# memo.txtの編集
git-sample % vi memo.txt
# memo.txtの修正をステージングに追加
git-sample % git add -A
# 直前のcommitと結合、実行するとコミットメッセージの編集ファイルが開く
git-sample % git commit --amend
[main d0c71f3] 3回目のcommitと４回目の編集
Date: Wed May 28 12:49:22 2025 +0900
1 file changed, 4 insertions(+)
# 再度、現在のcommit履歴を確認
git-sample % git log --oneline
d0c71f3 (HEAD -> main) 3回目のcommitと４回目の編集
2400efa 2回目のcommit
eb84fe0 1回目のcommit上記のように、コミットメッセージを編集しながら、直前のcommitに修正を追加することができました。commitを何回もしていると、修正漏れが発生することがあります。git commit –amendを利用すれば直前のcommitに追加できるため、不要なcommitを増やさずに履歴を管理できます。
⚠️ 他人と共有済みの履歴を
--amendで書き換えると、そのコミットIDが変わり、他の開発者に影響します。必ず共有前の段階でのみ使うようにしましょう。
▶︎git stash 「一時的に作業を保留」
【使う場面】
- 作業中だが、急ぎで別のブランチへ移動したい
- コミットするには中途半端、でも一旦ファイルを退避させたい
- PRの確認だけしたいが、作業中のファイルが邪魔になる
stash は、ワーキングツリーとインデックスの変更を一時的に退避し、作業ディレクトリをクリーンな状態に戻すためのコマンドです。あとから再開したり、他のブランチへ移動しても安心です。作業途中の開発をstashに退避するイメージは下記の図ようになります。
💡 なぜ stash を使うのか？ Gitでは、コミットされていない変更があると
git checkoutやgit switchが制限されることがあります。変更内容を無理やりコミットすると、「意味のない中途半端なコミット」が履歴に残ってしまいます。stashを使えば、そういった不要な履歴を残さずに安全に作業を中断・再開できます。
【使い方】
git stash # 変更を一時的に保管
git stash list # 保管された作業一覧を確認
git stash pop # 最新のスタッシュを取り出して適用
git stash apply # スタッシュを適用（消さずに残す）
git stash drop # スタッシュを削除
git stash clear # すべてのスタッシュを削除
⚠️
stashは便利ですが、「stashして忘れる」問題がよくあります。git stash listでこまめに中身をチェックし、不要なものは削除しましょう。「一時的に作業を保留」
まとめ
- 「コミットを多すぎた」「メッセージを誤った」といった履歴のミスは、ツールを知っていれば整えられます
rebase,amend,stashは、使い手を覚えればとても強力なGit技法- 「どう使うか」よりも「なぜ使うか」を認識しておくのが大事
履歴は自分の足跡。美しく整えて、チームの財産にしていきましょう。
