Gitを大規模運用するのはなぜ難しいのか Cursorが語る技術的課題
Git at any scale
Gitは分散型バージョン管理システムとして設計されたが、大規模な集中管理型ホスティングには不向きだ。Cursorのブログ記事は、Gitのパックファイル形式がスケーラビリティと可用性の制約となることを指摘し、分散ファイルシステムやオブジェクトレベルの分散など過去の試みが失敗した経緯を解説。GitHubのSpokesシステムが、パックファイルをNVMeに保存し、コンセンサスアルゴリズムで複製を同期することで、一貫性を保ちながらスケールアウトを実現したと述べている。
「Gitを大規模にホスティングすることは悪夢だ。Gitの分散設計は、平均的な企業のワークフローにはむしろ妨げとなる。」
- brasic
この記事の著者の評判は、いくら強調してもしすぎることはありません。GitHubの内部システムの良いところはすべて彼の名前がついているように思えました（数年前とは意味合いが変わってきているのは承知しています）。私と彼のGitHubでの時期はあまり重なっていませんが、彼がCursorで働いているという事実を聞いて、彼らのエンジニアリング組織に対する私の評価は飛躍的に高まりました。
- biwills
> コンセンサスはどうなのか？ 選挙は？ 特定のリポジトリのプライマリはどのサーバーなのか？ それも重要ではない！ ここには状態もコンセンサスもない。どのサーバーでもプライマリになれる。すべての書き込み先行ログへの更新は、S3上のアトミックな比較交換（CAS）操作で同期されるため、どのリポジトリのインスタンスがプッシュを受け取っても常に安全なのだ。
S3がどれほど素晴らしいエンジニアリングの成果であるかを、また思い知らされた（耐久性99.999999999% - イレブンナイン）[1]
1: https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDu...
- vegadw
覚えておいてください、大きなオブジェクトをcntに入れないでください。後で本当に面倒なことになります。