📓 このブログを書く目的
自分のため（アウトプットの練習）
📝 このブログから学べること
Pushしてしまった過去のコミットを安全に修正する手順
📌 手順
1️⃣ 特定コミットの修正
-
git rebase -iコマンドで、特定のコミットを「edit」モードで編集
# 修正したいコミットの1つ前を指定
git rebase -i XXXXXXXXXXX^
# エディタが開いたら、修正したいコミットの行の「pick」を「edit」に変更
edit XXXXXXXXXXX [feature]コミットメッセージなんちゃらかんちゃら
# 以下の行はそのまま
pick 2XXXXXXXXXX [fix]コミットメッセージなんちゃらかんちゃら
pick 3XXXXXXXXXX [update]コミットメッセージなんちゃらかんちゃら
2️⃣ リベースプロセス一時停止後、過去にコミットしたファイルを修正する
- 👩💻＜ｼｭｳｾｲ！
3️⃣ リベースプロセス一時停止をおわる
# ファイルを編集後
git add .
git commit --amend --no-edit # コメントそのままで
git rebase --continue # 一時停止おわりにします
4️⃣ 変更の反映
- 強制プッシュ（
--force-with-leaseオプション付き）で変更を反映
git push --force-with-lease origin feature/XXXXXXXXXXXXXXXXXXXX
🌟 ポイント解説
「edit」モードとは？
リベース中の「edit」は「このコミットで一時停止して編集させて」という指示です。
これにより、コミット内容だけを変更し、メッセージはそのままにできます。
「--force-with-lease」の安全性
通常の --force はドキドキですが、--force-with-lease は「他の人が同時に変更していないことを確認してから強制プッシュする」という安全装置付きです。
チーム開発では常にこちらを使うのが得策に感じます。
リベースによる履歴の書き換え
リベースはコミット履歴を「書き換える」操作です
これにより以下が発生します
- コミットハッシュが変わります（同じ内容でも新しいハッシュに）
- マージコミットが解消され、直線的な履歴になります
- コミットの順序が整理されます
🕊️ より安全に作業をするために
ポイント解説にも記載しましたが、リベースはコミットハッシュが変わります。
「--force-with-lease」を利用しても、以下の問題は解決できません。
＜問題＞
- 参照切れ: JIRAなどでコミットハッシュを参照している場合、リンクが切れます
- レビュー影響: PRのレビューコメントが「古い変更」として扱われる可能性があります
- チーム混乱: 「バグは#abc123で修正した」といった会話が通じなくなります
問題が関係ありそうな場合は、以下のような対策をとったほうがいいかもです。
＜対策＞
- 適用範囲を限定: 個人ブランチや未マージのPRでのみリベースする
- 事前通知: チームメンバーに変更を事前に伝える
- タグの活用: 重要な参照点にはコミットハッシュでなくタグを使う
リベースは強力なツールですが、チーム開発では注意して使いましょう！
🙄 ..（そのまま修正して再プッシュすれば？）
💡 もちろん！それもありだとおもいます。
が、わたしは、チーム開発でレビューをしてもらう立場でした。
なので、自身の立場を踏まえ、以下を意識していました。
＜意識していたこと＞
- コミット履歴はなるべく綺麗に（軽微な修正とコミットを繰り返さない）
- レビューの指摘対応は指摘ごとにコミットする
- このコミットでは、こんな修正してます！ということが分かりやすくなるようにする
✨️参考にしてる考え方
そんなこんなで、リベースにたどり着いたのでした。
💡 まとめ
Gitは過去のコミットは、rebase -i と --force-with-lease の組み合わせで修正できます。
履歴をクリーンに保ちながら安全に作業するためにとっても便利です😄
いじょう！
だれかのお役にたてればさいわいです
（つぎは、リベース中にコンフリクトが発生した場合の対処法についても書こうかな🤔）