未コミット195ファイル、4プロジェクト分をどう片付けたか

ロボットが書類の山を4つの棚に仕分けているイラスト コラム

「全体的に未コミットのものがあるから確認して」

自分でそう頼んでおきながら、返ってきたgit statusの結果を見て面食らった。別ジャンルのコンテンツ制作プロジェクトの素材、子供向けアプリの画面ファイル、記事の執筆ルール、日次のKPIログ。まったく畑違いの変更が、同じ画面にずらりと並んでいた。

作業は完結していたのに、記録の工程だけが抜けていた

原因ははっきりしていた。複数のプロジェクトを、それぞれ別のタイミングでAIエージェントに任せていた。コンテンツ制作プロジェクトの一つはすでに自動コミットの仕組みを持っていて定期的に記録が残る一方、子供向けアプリの機能追加や、記事の書き方ルールの整備は、作業が終わった時点でコミットする習慣がなかった。個々の作業は完結していたのに、「区切りをつけて記録する」工程だけが抜け落ちていた。

最終的に数えると、未コミットのまま積み上がっていた変更は4プロジェクトにまたがり、合計で195ファイルにのぼっていた。

「まとめて1コミット」は選ばなかった

一番早いのは、全部まとめて1コミットにしてしまうことだった。だが、それは選ばなかった。

理由は単純で、あとから見たときに何が起きたのか説明できなくなるからだ。半年後にログを追う自分は、「アプリに新機能を足した」変更と「記事のルールを整備した」変更を、同じコミットの中から仕分けなければならなくなる。片方だけ取り消したくなったときも、簡単には戻せない。無関係な変更を1つのコミットに混ぜることは、未来の自分から選択肢を奪う行為だ。

意味のまとまりで4つに割った

代わりに、変更をプロジェクトと意味のまとまりで4グループに分類した。

  1. 記事の書き方ルール一式(新設ドキュメント・関連スキル)
  2. 別ジャンルのコンテンツ制作プロジェクトの進行分(素材ファイル一式)
  3. 子供向けアプリの新機能一式(画面・アセット)
  4. KPIログや投稿キューなど、定型的に更新される日次データ

git addで対象ファイルを個別に指定し、グループごとに意味の通じるコミットメッセージを付けて、順番に確定させていった。ファイル数で言えば、7件・72件・111件・5件。合計すると最初の195件と一致する。

「粒度を細かくしすぎでは」への答え

そうは言っても、4つに分けるくらいなら手間も大差ないのでは、という声はあるはずだ。だが粒度を揃える作業は、コミットを作る側のためではなく、あとで読む側のためにある。git logを1行ずつ追ったとき、「このコミットは何をしたものか」が1行で言えるかどうかが基準になる。195件をまとめた1行のメッセージでは、それは言えない。

git logがタイトルだけで読める状態に戻った

作業を終えてgit logを見返すと、直前の数コミットがそれぞれ何をしたか、タイトルだけで把握できる状態に戻っていた。当たり前のようで、これは崩れると簡単には元に戻らない状態だ。

複数のプロジェクトを並行してAIエージェントに任せるなら、進捗の確認だけでなく、記録の区切りをつける工程も定期的に見にいく必要がある。次に確認するのは、もっと溜まる前のタイミングにしようと思う。

同じようにAIエージェントへ作業を任せている人は、一度git statusを打ってみてほしい。区切りを失った作業が、想像より多く並んでいるかもしれない。


私は現役EMとして、1on1やチーム運営の仕組み化について書いています。1on1管理のNotionテンプレート(無料Lite版)を公開中です → 試してみる。X: @anikuma_tech

コメント