#ソース管理

最初に思ったのは、「また monorepo か」ではなく、Anthropic ほどの規模でも自前で source control を作り直すのは、よほど今の仕組みに痛みがあるのだろうなということだった。monorepo は一見すると「全部ひとつにまとめれば楽そう」に見えるけれど、実際には権限管理、差分の扱い、ビルド時間、レビューの流れまで巻き込む。そこをわざわざ設計し直すというのは、単なる流行追随ではなく、組織の開発体験そのものを変えたい意図があるのだと思う。 ただ、ここで少し引っかかるのは、こういう話が会社の内側ではものすごく効く一方で、外から見ると成果が見えにくいことだ。新しいモデルや機能の話なら「速くなった」「便利になった」とわかりやすい。でも source control は地味だし、うまくいっても派手には見えない。だからこそ、こういう基盤に投資できる会社は強いのだろうとも思う。派手な機能の前に、毎日の開発で感じる摩擦を減らす。その積み重ねが結局いちばん効くのかもしれない。 一方で、monorepo をうまく扱う仕組みは、会社ごとの文化や規模にかなり依存するはずだ。記事

いちばん面白かったのは、Anthropic が困った理由そのものより、「そりゃ Git の前提だと苦しいよね」と腑に落ちたところです。 ふつう Git は、開発者がローカルに丸ごと持っていって、オフラインでも作業できることに価値があります。でもこの記事で描かれているのは、コードを書く主体が人間だけではなく、Claude のような agent や CI の job になっていて、しかもそれらが常時オンラインで動いている世界です。そこで「全部を手元に持つ設計」が重荷になるのは、かなり自然だと思いました。 特に引っかかったのは、Git が優れていた性質そのものが、規模が変わると足を引っ張るという点です。 履歴が大きくなりすぎると clone や checkout が重い、という話はよく聞きますが、この記事はその先まで踏み込んでいて、差分取得や blame のような「ちょっとした問い合わせ」まで、もはやローカル前提では回らないところまで行っている。しかも Anthropic では、単に人が困っているのではなく、機械が毎日大量にコードを動かすので、問題が一気に表面化する。ここはかなり現代的だなと

Git では「追跡したくないものを後から消す」やり方が当たり前になっています。けれど今回の元記事は、その発想をひっくり返して、最初から全部無視し、必要なものだけを明示的に許可する運用を提案しています。たしかに、ローカルに散らばる不要ファイルや秘密情報の混入が増えた今、この考え方は昔より現実味があります。単なる小ネタというより、チームの事故を減らすための設計の話として読むと面白いです。 元記事の主張は、`.gitignore` を「不要なものを後から足していく設定」ではなく、「最初に全部を無視し、残したいものだけを許可する設定」に変えてみないか、というものです。著者の Alex Pliutau は、`.DS_Store`、`node_modules`、IDE の設定ファイル、さらには `CLAUDE.md` のようなローカル向けのファイルまで、気づかないうちにコミットしてしまう経験を挙げています。もっとまずいのは environment variables の混入だと言います。こうしたものが repository に入ると、掃除のために `.gitignore` を直し、履歴からも消し、