はじめに
Git 2.54 がリリースされ、git history という新しい実験的コマンドが追加されました。 コミット履歴の修正といえば git rebase -i が定番ですが、「直近のコミットメッセージに typo があった」「一つのコミットを二つに分けたい」だけの場面では、インタラクティブリベースの段取りが少し大げさに感じることがあります。 PR レビュー直前に typo に気付いて git rebase -i を起動したとき、todo リストの編集から始める手順を経るのが少し煩わしいと感じたことが筆者にもありました。 今回は git history の基本的な使い方と、どんな場面で役立つかをまとめます。
git history とは
git history は、ピンポイントな履歴の書き換えに特化した実験的コマンドです。 git rebase -i のような「やることリスト（todo）を用意してリベースを進める」という手順を踏まず、修正したいコミットを一発で指定できます。
現時点ではサブコマンドとして reword と split の 2 つが用意されています。
注意：本コマンドは実験的扱いです。インターフェースは今後変更される可能性があります。
git history reword — コミットメッセージを書き直す
使い方
git history reword <コミットハッシュ>コマンドを実行するとエディタが開き、指定したコミットのメッセージを編集できます。 保存して閉じると、そのコミット以降の子孫ブランチも自動的に更新されます。 作業ツリーやインデックスには一切触れないため、作業中の変更を退避させる必要がありません。
実例
コミット a1b2c3d のメッセージに typo があった場合を例にします。
# コミット履歴を確認する
git log --oneline
# a1b2c3d fix: レスポンスのキャシュ処理を修正する ← typo あり
# 9e8f7d6 feat: 検索APIを追加する
# メッセージを書き直す
git history reword a1b2c3dエディタが開くので、メッセージを修正して保存します。
fix: レスポンスのキャッシュ処理を修正する保存して閉じると履歴が更新されます。
git rebase -i との違い
git rebase -i HEAD~3 でも同じことはできますが、手順が増えます。
| 操作 | git rebase -i | git history reword |
|---|---|---|
| todo リストの編集 | 必要（reword に変更） | 不要 |
| 作業ツリーへの影響 | あり | なし |
| ベアリポジトリでの実行 | 不可 | 可 |
typo の修正のような単純な作業には git history reword のほうがシンプルに完結します。
git history split — コミットを分割する
使い方
git history split <コミットハッシュ>ハンク（差分のひとかたまり）を対話形式で選択し、指定したコミットを 2 つに分割します。 選択したハンクが新しい親コミットとして切り出され、残りのハンクが元のコミットに留まります。
pathspec を指定してファイル単位で絞り込むこともできます。
# 特定ファイルに関する変更だけを分割対象にする
git history split a1b2c3d -- src/api.ts実例
「フォームのバリデーション修正」と「API クライアントの修正」が一つのコミットにまとまってしまった場合を例にします。
git log --oneline
# b4c5d6e fix: フォームバリデーションとAPIクライアントを修正する
# ...このコミットを 2 つに分けたいとき、以下のように実行します。
git history split b4c5d6eハンク選択の画面が表示されます。 y で「新しい親コミットへ切り出すハンク」を、n で「元のコミットに残すハンク」を選択します。
diff --git a/src/form.ts b/src/form.ts
@@ -10,6 +10,10 @@
...
(1/2) Split this hunk? [y,n,q,?]選択が完了すると、履歴が 2 コミットに分かれます。
git log --oneline
# b4c5d6e fix: APIクライアントを修正する ← 元のコミット（残したハンク）
# a3b4c5f fix: フォームバリデーションを修正する ← 切り出されたコミット
# ...どんな場面で便利か
- PR レビュー前に「1 コミットに詰め込みすぎた」と気付いたとき
- CI で失敗したコミットと無関係な変更を切り分けたいとき
git add -pで分割してコミットすべきだったが、まとめてしまったとき
注意事項
git history には現時点で以下の制限があります。
- マージコミットを含む履歴には対応していない：マージコミットが存在する場合、コマンドは実行を拒否します。
- マージコンフリクトが発生する操作は行えない：コンフリクトが予測される場合も中断されます。
- 実験的コマンドのためインターフェースが変わる可能性がある：スクリプトへの組み込みは慎重に判断することをおすすめします。
まとめ
Git 2.54 の git history は、git rebase -i の代替というよりも、ピンポイントな履歴修正専用のツールです。 コミットメッセージの typo 修正には reword、詰め込みすぎたコミットの分割には split を使うことで、インタラクティブリベースの煩雑な手順を省けます。 実際に使ってみると、reword の手軽さは git commit --amend に近い感覚でした。split は git add -p の操作感そのままでコミットを切り分けられるため、git add -p に慣れている方にはすぐ馴染めると思います。 まだ実験的なコマンドのためスクリプトへの組み込みは避けたほうが無難ですが、手作業での履歴整理用途であれば試す価値はあります。
コメント