CODE IN TOKYO

AI時代のGit運用：「汚い作業履歴」と「綺麗なメイン履歴」を分離する

2026年5月某日：また「謎のコミット」が増えていた

今日もGitの履歴を眺めながら、少し笑ってしまった。

fix lint
fix type
retry
temporary workaround
revert
another fix

これは最近、AIエージェントにコードを書かせていると本当によく見る。

人間でも作業中のコミットは汚くなりがちだが、AIはさらに細かくコミットを刻む。

みたいな試行錯誤を高速で回すからだ。

AIにとっては「細かく保存しておく」方が合理的なので、これはある意味当然の挙動でもある。

Gitの履歴は、昔より汚れやすくなっている

昔は、ある程度まとまった単位で人間がコミットしていた。

でもAI時代になると、コミット数そのものが増えやすい。

しかもAIは、人間ほど：

みたいな美意識を持たない。

結果として、作業ブランチはかなりカオスになる。

ただ、個人的にはこれは悪いことではないと思っている。

作業履歴が汚いのは、実は自然

そもそも作業中の履歴なんて、本来かなり泥臭い。

実際、人間でも：

fix
fix2
ほんとのfix
typo
WIP

みたいになる。

これは「思考ログ」だからだ。

むしろ最初から綺麗すぎる履歴の方が、あとから作られた「化粧された歴史」に近い。

だから作業ブランチが多少汚いこと自体は、そこまで問題ではない。

問題は、その汚い履歴がmainに流れ込むことだ。

だからSquash Mergeがかなり合理的

個人的に今かなり合理的だと思っているのが、

Squash Merge（スクワッシュマージ）。

つまり：

という運用。

これがAI時代とかなり相性が良い。

例えば作業ブランチでは：

fix lint
retry
temporary fix
revert
another fix

みたいになっていても、

最終的にmain側では：

ユーザー一覧API追加

だけ残せばいい。

これなら履歴が「機能単位」で読める。

ここまでが「mainに入れる時」の話

Squash Mergeが解いているのは、

「AIの大量コミットをmainに残さない」

という、main側の問題だ。

ただ、Git運用にはもう一つ別の問題がある。

それが、作業中のブランチを、最新のmainに追従させる話。

こちらはコミット数を減らす問題ではなく、自分のブランチをずれないように保つ問題で、Squashとは目的が違う。

作業中の追従で使うrebaseと、その怖さ

main追従の伝統的な方法がrebase。

git fetch origin
git rebase origin/main

履歴は一直線になる。

技術的には美しい。

ただ、現実にはかなり嫌われる。

コンフリクト地獄、force push事故、共有ブランチ破壊と、今でも普通に事故るからだ。

なお、rebaseはあくまで並び替えで、fix lint / retry / revert のような大量コミットそのものは残る。

コミット削減はSquash、ブランチ追従はrebase、と役割は別物。

ただ、Squashで綺麗になるなら、rebaseいらなくない？

ここまで書いて、自分でも一つ引っかかる。

rebaseには確かに利点がある。履歴が一直線、merge commitのノイズが入らない、PRが読みやすい。

ただ、Squash Mergeを採用している時点でmain側は1コミット化されるので、作業ブランチの形はそもそも残らない。

つまりrebaseで残る価値はPRレビュー時の見やすさくらいで、かなり美観寄りの話。

逆にデメリットはforce-push必須・コンフリクト再発・AIの文脈ロスと、地味に効く。

個人ブランチでmain追従するだけなら、

git pull

で十分だったりする。

「rebaseを個人ブランチでAIに任せる」のはアリ。

ただ、Squash前提では必須ではない、というのが今のところの感覚。

AI時代のGit運用は「汚く作って、綺麗に残す」

昔は、

「綺麗にコミットしろ」

と言われがちだった。

でもAI時代になると、むしろ：

という運用でもいい気がする。

主役はあくまでSquash Merge、rebaseはオプションくらいに整理すると、考えることが減る。

Gitの思想そのものは変わらない。

重要：GitのpullとRebase論争は神学論争なので、これはただのお気持ち表明です。異論は聞かない（笑）