【ITニュース解説】Split a Coding Agent's Giant Commit With git history split (Git 2.54+)

ソフトウェア開発において、Gitはコードの変更履歴を管理するための非常に重要なツールだ。開発者はコードの変更を「コミット」として記録し、プロジェクトの進化を追跡していく。しかし、時には一つのコミットに複数の、互いに関連性の低い変更が混在してしまうことがある。例えば、緊急で修正すべきバグと、将来的な機能改善のために大規模なコード構造の見直し（リファクタリング）が、不注意にも同じコミットとして記録されてしまうような状況だ。特に近年では、AIを活用したコーディングエージェントが複数のタスクを一度に処理し、その結果を一つの巨大なコミットとして提示するケースも見られる。

このような「巨大コミット」は、開発プロセスにおいて様々な問題を引き起こす。例えば、バグ修正だけを緊急でリリースしたいが、そのコミットにはまだ議論が必要なリファクタリングも含まれていると、変更全体を適用するか、全く適用しないかの二択しかなく、バグ修正だけを素早くデプロイすることが難しくなる。また、コードレビューの際にも、一つのコミットに様々な目的の変更が含まれていると、レビュー担当者は混乱しやすくなり、重要な変更を見落とすリスクが高まる。これは、開発の効率性を低下させ、コード品質の維持を困難にする要因となる。

これまでのGitでは、このような巨大コミットを分割して整理するには、「インタラクティブリベース（git rebase -i）」というコマンドを使うのが一般的だった。しかし、この方法はコミットの履歴を一時的に停止し、手動でコミットをリセットしてから変更内容を一つずつ再ステージングし、複数の新しいコミットとして再作成するという、手順が複雑で習得に時間がかかる操作だった。特にGitの扱いに慣れていないシステムエンジニアの初心者にとっては、ミスを犯しやすい、敷居の高い作業であったと言えるだろう。

しかし、Git 2.54以降のバージョンで、「git history split」という新しい実験的なコマンドが導入された。このコマンドは、巨大コミットをより簡単かつ直感的に分割できるように設計されている。開発者は、特定のコミットに含まれる変更内容（Gitではこれを「ハンク」と呼ぶ）を、まるでgit add -pコマンドでファイルの一部をステージングする時のように、一つずつ選択しながら、新しいコミットとして切り出すことができる。これにより、緊急のバグ修正と将来のリファクタリングといった異なる目的を持つ変更を、それぞれ独立したコミットとして適切に分離し、管理することが可能になる。

git history split コマンドを使うと、まず対象となるコミットを指定する。例えば、最新のコミットの前のコミットを分割したい場合は git history split HEAD~1 と入力する。すると、Gitはそのコミットに含まれる変更を、ファイルごと、そしてそのファイル内のハンクごとに順番に提示していく。ユーザーは、提示された各ハンクに対して、以下の選択肢で対応する。

• y：このハンクを、これから作成する「新しいコミット」に含める。
• n：このハンクは、元のコミットに残しておく。
• d：このハンクと、そのファイルに残っているすべての変更を元のコミットに残しておく。

このようにして、例えばバグ修正に関するハンクだけを「y」と選択し、リファクタリングに関するハンクは「n」とすることで、バグ修正のみを切り出して新しいコミットとして作成できる。もし変更が複数のファイルにまたがっていて、特定のファイルだけを新しいコミットに含めたい場合は、git history split HEAD~1 -- src/Money.php tests/MoneyTest.php のようにファイルパスを指定することもできる。これにより、指定したファイル以外の変更は自動的に元のコミットに残されるため、作業の手間を減らせる。ハンクの選択が終わると、Gitはまず、ユーザーが選択したハンク群で構成される新しいコミットのためのコミットメッセージの編集画面を表示する。次に、残りのハンク群で構成される元のコミットのコミットメッセージの編集画面が表示されるため、それぞれのコミットがその内容を正確に反映したメッセージを持つことができる。

コミットを分割した後、git log --oneline main..agent/checkout のようなコマンドで履歴を確認すると、元々一つだった巨大コミットが、二つの独立したコミットに分かれていることがわかる。しかし、git diff before-split agent/checkout のように、分割前と分割後の最終的なコードの状態を比較すると、コードの内容自体は変わっていないことが確認できるはずだ。これは、git history split がコードそのものを変更するのではなく、コミット履歴の構造を再編成しているだけであることを意味する。

さらに、Git 2.54ではコミットメッセージの修正をより簡単にする「git history reword」も追加された。これは、過去の任意のコミットメッセージを、git commit --amendで最新のコミットを修正するのと同様に、手軽に編集できるコマンドだ。ワーキングツリーやインデックス（次にコミットされる変更が一時的に置かれる場所）に影響を与えることなく、単にコミットメッセージだけを修正できるため、コミット履歴をより明確に、そして正確に保つのに役立つ。そして、Git 2.55では、ステージングされた変更を過去の特定のコミットに統合する「git history fixup」が導入された。これは、例えば後から見つかったテストの追加や、細かな修正を、本来それらが属すべき過去のコミットに遡って結合したい場合に非常に便利だ。git history fixup 'agent/checkout^{/Fix zero}'のように、コミットメッセージの一部を正規表現で指定して対象コミットを見つけることもできる。Git 2.56では、特定のコミットを履歴から削除し、その子孫コミットを親コミットに再適用する「git history drop」も加わり、より柔軟な履歴操作が可能になった。

ただし、これらのgit history系のコマンドは、まだ「実験的」な機能として提供されており、将来的にその挙動が変わる可能性があることに注意が必要だ。また、いくつかの制限事項も存在する。例えば、履歴の中にマージコミットが含まれる場合は使用できない。そのような状況では、git rebase --rebase-mergesといった別のコマンドを使う必要がある。さらに、これらの操作がコードの衝突（マージコンフリクト）を引き起こす可能性がある場合、Gitは処理を停止するのではなく、操作全体を拒否する。これは、ユーザーを中途半端で解決が難しい状態に残さないための配慮だ。他にも、特定のGitフック（コミット時に自動で実行されるスクリプト）が実行されない場合があること、ハンクの細かい編集（eオプション）ができないこと、空のコミットが生成されるような選択はできないこと、といった点も理解しておくべきだ。

git history split は、開発者が一つ一つのコミットをよりクリーンに保ち、コードレビューを容易にし、変更の管理をより効率的に行うための強力なツールだ。特にAIエージェントによるコード生成が増加する中で、意図せず混入してしまった巨大コミットを、手動での複雑な作業を伴わずに簡潔に整理できる点で大きなメリットがある。これらの新しいコマンドを理解し、適切に使いこなすことで、システムエンジニアを目指す初心者は、より洗練されたGitワークフローを構築し、開発プロセスをスムーズに進めることができるようになるだろう。