Gitユーザーは、複数の低レベルな操作を手作業で組み合わせなくても、以前のコミットを修正できる実験的な方法を利用できるようになった。2026年7月14日の出来事の日付時点で、`git history`コマンドには`fixup`、`reword`、`split`という3つのサブコマンドがあり、ローカルブランチのポインターを整合させたまま、リポジトリのコミットグラフで影響を受ける部分を再構築するよう設計されている。

開発者ラリット・マガンティによる技術解説によれば、このコマンドは段階的に導入された。Git 2.54では4月に`reword`と`split`が導入され、バージョン2.55では6月に`fixup`が追加された。Git自体に同梱されているが、依然として実験的な機能である。

`git history fixup <commit>`を使うと、開発者は修正をステージングし、それを過去の対象コミットに組み込める。そのコミットを変更すると新しいハッシュが生成されるため、そこから派生した後続のコミットも再作成しなければならない。このコマンドはその再構築を処理し、修正されたコミットから派生するローカルブランチを移動する。マガンティは、その適用範囲が、現在リベース中の範囲内にある参照だけを更新する`git rebase --update-refs`より広くなる場合があると指摘した。ユーザーは操作を現在のブランチだけに限定することもできる。

`reword`サブコマンドは、同じ大枠の考え方をコミットメッセージに適用する。選択したコミットの既存メッセージを編集用に開いた後、後続のコミットを再作成し、関連するブランチポインターを進める。基礎となるファイル内容は変更されないため、この操作はコミットグラフ上で機能し、インデックスや作業ツリーには影響を与えない。

一緒にすべきでなかった変更については、`git history split <commit>`が、選択したコミットの差分をハンクごとに対話形式で提示する。選択したハンクが最初の置換コミットを構成し、残りが2番目のコミットになる。その後、派生コミットがこの2つの上に再構築される。

中心的な制約も安全モデルの一部となっている。historyの各操作は、競合が生じる場合には処理の続行を拒否する。このため、試行される各書き換えはアトミックとなり、不完全な中間状態を回避できるが、同時にツールが現在処理できる範囲も限定される。解説によると、マージコミットが存在する場合、`fixup`は機能しない。

マガンティは、この機能を、競合を第一級オブジェクトとして扱い、リベース中に競合状態を保持できる別のバージョン管理システム、Jujutsu（`jj`）と比較した。Gitのコマンドはその動作を再現しておらず、`jj`の操作ログ、容易な取り消し機能、作業コピーをコミットとして扱うモデルも提供しない。その魅力はより限定的で、互換性にある。開発者は、すでに使用しているGitのインストール環境とワークフロー内で、構造化された履歴編集を試せる。

したがって、導入を評価するチームにとってトレードオフは明確だ。このコマンドは、一般的なローカルでの書き換えに伴う手作業の段取りを減らし、依存するブランチを自動的に追従させるが、競合時には処理を拒否し、マージにも制限があるため、対話的リベースや代替のバージョン管理ツールを全面的に置き換えるものではない。