Git では「追跡したくないものを後から消す」やり方が当たり前になっています。けれど今回の元記事は、その発想をひっくり返して、最初から全部無視し、必要なものだけを明示的に許可する運用を提案しています。たしかに、ローカルに散らばる不要ファイルや秘密情報の混入が増えた今、この考え方は昔より現実味があります。単なる小ネタというより、チームの事故を減らすための設計の話として読むと面白いです。
元記事の主張は、.gitignore を「不要なものを後から足していく設定」ではなく、「最初に全部を無視し、残したいものだけを許可する設定」に変えてみないか、というものです。著者の Alex Pliutau は、.DS_Store、node_modules、IDE の設定ファイル、さらには CLAUDE.md のようなローカル向けのファイルまで、気づかないうちにコミットしてしまう経験を挙げています。もっとまずいのは environment variables の混入だと言います。こうしたものが repository に入ると、掃除のために .gitignore を直し、履歴からも消し、誰にも見られていないことを願う、という面倒な後始末が必要になります。
そこで著者が示すのが、反対の書き方です。例として挙げているのは、Go の小さな project 向けの .gitignore で、最初に * を置いて全ファイルを無視し、そのうえで !.gitignore、!*.go、!README.md、!go.mod、!go.sum を並べています。! は「このファイルは例外として追跡してよい」という意味です。つまり、Git は原則として何も見ないが、.gitignore 自体、Go の source file、go.mod、go.sum、README だけは通す、という構造です。著者はこの方式なら、意図しない local file をうっかり commit する事故をかなり減らせると言っています。
ただし、これがすべての repository や開発者に向いているとまでは言いません。著者自身も、これは「試してみる価値のある alternative」だと位置づけています。そのうえで、今の project には agentic docs のようなローカル生成物やサブフォルダが増えすぎていて、最初から全部無視するほうがむしろ分かりやすい場面がある、と述べています。例として、typescript-go の 207 行ある .gitignore にも触れており、無視対象が膨れあがるなら、最初に白紙のルールで始めるほうが管理しやすい、という感覚を示しています。最後に、Git がある path を無視しているか確認するには git check-ignore -v internal/server/server.go を使うとよい、と実用的なコマンドも添えています。
この発想の面白さは、.gitignore を単なる掃除道具ではなく、許可制の gate として使っている点にあります。普通は「これはいらない」「あれもいらない」と例外を積み上げますが、そこには人間のうっかりが入り込みます。しかも今の開発環境は、昔よりずっと雑多です。editor の設定、AI 補助ツールのメモ、ローカルキャッシュ、生成されたドキュメント。どれも放っておくと repository に紛れ込みやすい。そう考えると、「まず全部止める」はかなり筋が通っています。特に、少人数で速く回す project や、取り込むファイルの種類が少ない service では、メリットが見えやすいはずです。
ただ、私はこれは万能な作法ではないとも思います。理由は単純で、例外を毎回明示する方式は、repo の中身が増えるほど管理コストが上がるからです。著者が例に出した Go の小さな project なら *.go や go.mod を許可するだけで済みますが、frontend、generated code、設定ファイル、画像、テストデータが混ざると、許可リストはすぐに長くなります。その段階では「何を入れないか」より「何を入れてよいか」を維持するほうが難しくなる。つまり、事故を減らせる代わりに、運用ルールを厳密に保てる人向けのやり方です。雑に扱うと、今度は「追跡したいのに無視されていた」トラブルが起こります。
この手法を採ると、問題は「余計な file を入れてしまう」から「必要な file を許可し忘れる」に移ります。私はここが本質だと思います。前者は恥ずかしい漏洩やノイズの混入につながりやすい。一方、後者は気づきにくいまま開発の流れを止めます。たとえば git check-ignore -v を使えば原因は追えますが、毎回それを調べるのは面倒です。だからこそ、この方式は「追跡対象が少なく、ルールを固定しやすい repo」では強く、逆に「人や用途が増えていく repo」では慎重に扱うべきだと思います。
それでも、著者の問題提起はかなり現代的です。昔の .gitignore は、主に build artifacts や OS が吐くゴミを弾くためのものだった印象があります。今はそこに、AI 補助ツールのメモや、ローカルでしか意味を持たないドキュメントまで混ざる。無視すべきものが増えたのではなく、「最初から入れたくないもの」が増えた、と言ったほうが近いかもしれません。そうなると、除外リストを増やし続けるより、許可リストで管理する発想のほうが、むしろ自然に見えてきます。
.gitignore を整える話は、実はチームの信頼の話でもあるもうひとつ大事なのは、.gitignore の設計がそのままチームの心理的な安全性に効くことです。コミットに不要な file が混じると、見つけた人が直す手間を負い、履歴から消す作業まで発生します。秘密情報ならなおさらです。そういう後始末は、技術的な面倒さ以上に、もうやりたくない失敗として記憶に残ります。最初から「通すものだけ通す」ルールにしておけば、コードレビューの段階でも判断しやすい。何が repository の外にあるべきかが、暗黙の空気ではなく file の形で見えるからです。
一方で、この考え方は「小さな repo の美学」を少し変えるとも感じます。シンプルな project ほど、git add . で何でも入る状態に慣れがちですが、それは裏返すと、境界が曖昧なまま増築していくやり方です。著者が紹介した方法は、その境界を最初に引くやり方です。私は、これを全員に勧めるべき標準作法だとは思いませんが、少なくとも「不要ファイルをどう消すか」ではなく「そもそも何を入れてよいか」から考えるきっかけにはなるはずです。今の開発環境の散らかり方を見ると、その視点のほうがむしろ健全ではないでしょうか。