FacebookがGitを使わない理由

xguru · 2024-03-12T10:31:01+09:00

Graphiteの開発者 Greg Foster がこれに関心を持った理由彼は Facebook の社内ツールに着想を得て Graphite プロジェクトを始めた Facebook 出身の同僚たちが Mercurial と "stacked diffs" ワークフローを紹介した後、GitHub 開発者向けにこれを導入することを決め、結果として Hg のアイデアを Git に統合した CLI を作ったなぜ Facebook は Git ではなく Mercurial を採用し、その上にカスタムワークフローを構築したのだろうか？ Google も Git を使っていないが、それは Google のエンジニアリングが Git より 5 年以上先行していたため一方で Facebook は Git が作られた時期とほぼ同じ 2004 年に設立されており、Facebook がソース管理ツールを本格的に検討した頃には Mercurial より Git のほうが人気だったそれなのに、なぜ Facebook は Git を使わないのか？彼の考えでは、もし Facebook が Git を採用し、2010 年代初頭にそこへ貢献していたなら、エンジニアリングの世界は違っていたはず Git はもっと使いやすくなり、ネイティブに Stacked Changes をサポートしていたかもしれない初期の Facebook 社員が作った Uber や Pinterest のような企業も、Mercurial ではなく Git と GitHub をソース管理に使い、この 10 年でもっと断片化の少ないエコシステムを作っていたかもしれないしかし Facebook は（メインのモノレポのために）Git を使い続けなかった。代わりにバージョン管理として Mercurial を採用し、その上にカスタムツールを段階的に追加していった Facebook に掲載された Scaling Mercurial at Facebook という記事を見つけた 10 年前の記事で、その後いくつかの YouTube 動画を通じて「性能が理由だ」という答えを得たしかし、さらに深く掘り下げて、当時の意思決定者たちの考えを聞きたくなり、Mercurial 移行プロジェクトに参加した 2 人のエンジニアに尋ねた彼らとの非公式な会話を通じて、この内容を整理した Facebook が Git を捨てて Mercurial に移行した理由 Facebook は当初 Git を使っていたが、2012 年ごろコードベースの規模が大きくなるにつれて性能問題を抱え始めた Git のファイル stat 処理がボトルネックとなり、基本的な Git コマンドの実行に 45 分以上かかっていた Git のメンテナーたちは Facebook の巨大リポジトリ問題に協力的ではなく、代わりにリポジトリの分割を勧めた検討された代替案 2012 年当時、Git の代替は多くなく、Facebook は Perforce のようなクローズドソースのソリューションも検討したが、技術的な問題があった Mercurial は Git と似た性能を持ちながら、よりクリーンなアーキテクチャと拡張性を備えていた Facebook のチームは Mercurial のハッカソンに参加し、Mercurial の拡張性とコミュニティのオープンさに感銘を受けたエンジニアリング組織全体の移行 Facebook のチームは残りの社内を説得するため、Git と Mercurial のコマンドやワークフローの対応関係を示し、開発者たちの懸念を聞く時間を設けた移行プロセスは慎重に進められ、最終的に Facebook は Mercurial へ切り替えた Facebook は Mercurial の性能向上に貢献し、さらに "stacked diffs" を通じてコードレビューの並列化を可能にするなどの貢献も行ったまとめの考えこの話は、「多くの重要な技術的意思決定は技術が主導するのではなく、人が主導する」という点を思い出させる Facebook は Mercurial が Git より高性能だったからではなく、Mercurial のメンテナーたちとの協業のほうがよりオープンだったため、それを選んだエンジニアリング組織全体を説得する過程では、ある技術が別の技術より優れていることよりも「思慮深いコミュニケーション」が重要だった「コミュニケーションと親切さ」が開発ツールの世界で重要な価値であることを強調している

(graphite.dev)

35 ポイント投稿者 xguru 2024-03-12 | 2件のコメント | WhatsAppで共有

Graphiteの開発者 Greg Foster がこれに関心を持った理由

彼は Facebook の社内ツールに着想を得て Graphite プロジェクトを始めた
Facebook 出身の同僚たちが Mercurial と "stacked diffs" ワークフローを紹介した後、GitHub 開発者向けにこれを導入することを決め、結果として Hg のアイデアを Git に統合した CLI を作った
なぜ Facebook は Git ではなく Mercurial を採用し、その上にカスタムワークフローを構築したのだろうか？
Google も Git を使っていないが、それは Google のエンジニアリングが Git より 5 年以上先行していたため
一方で Facebook は Git が作られた時期とほぼ同じ 2004 年に設立されており、Facebook がソース管理ツールを本格的に検討した頃には Mercurial より Git のほうが人気だった
それなのに、なぜ Facebook は Git を使わないのか？
彼の考えでは、もし Facebook が Git を採用し、2010 年代初頭にそこへ貢献していたなら、エンジニアリングの世界は違っていたはず
- Git はもっと使いやすくなり、ネイティブに Stacked Changes をサポートしていたかもしれない
- 初期の Facebook 社員が作った Uber や Pinterest のような企業も、Mercurial ではなく Git と GitHub をソース管理に使い、この 10 年でもっと断片化の少ないエコシステムを作っていたかもしれない
しかし Facebook は（メインのモノレポのために）Git を使い続けなかった。代わりにバージョン管理として Mercurial を採用し、その上にカスタムツールを段階的に追加していった
- Facebook に掲載された Scaling Mercurial at Facebook という記事を見つけた
- 10 年前の記事で、その後いくつかの YouTube 動画を通じて「性能が理由だ」という答えを得た
- しかし、さらに深く掘り下げて、当時の意思決定者たちの考えを聞きたくなり、Mercurial 移行プロジェクトに参加した 2 人のエンジニアに尋ねた
- 彼らとの非公式な会話を通じて、この内容を整理した

Facebook が Git を捨てて Mercurial に移行した理由

Facebook は当初 Git を使っていたが、2012 年ごろコードベースの規模が大きくなるにつれて性能問題を抱え始めた
Git のファイル stat 処理がボトルネックとなり、基本的な Git コマンドの実行に 45 分以上かかっていた
Git のメンテナーたちは Facebook の巨大リポジトリ問題に協力的ではなく、代わりにリポジトリの分割を勧めた

検討された代替案

2012 年当時、Git の代替は多くなく、Facebook は Perforce のようなクローズドソースのソリューションも検討したが、技術的な問題があった
Mercurial は Git と似た性能を持ちながら、よりクリーンなアーキテクチャと拡張性を備えていた
Facebook のチームは Mercurial のハッカソンに参加し、Mercurial の拡張性とコミュニティのオープンさに感銘を受けた

エンジニアリング組織全体の移行

Facebook のチームは残りの社内を説得するため、Git と Mercurial のコマンドやワークフローの対応関係を示し、開発者たちの懸念を聞く時間を設けた
移行プロセスは慎重に進められ、最終的に Facebook は Mercurial へ切り替えた
Facebook は Mercurial の性能向上に貢献し、さらに "stacked diffs" を通じてコードレビューの並列化を可能にするなどの貢献も行った

まとめの考え

この話は、「多くの重要な技術的意思決定は技術が主導するのではなく、人が主導する」という点を思い出させる
Facebook は Mercurial が Git より高性能だったからではなく、Mercurial のメンテナーたちとの協業のほうがよりオープンだったため、それを選んだ
エンジニアリング組織全体を説得する過程では、ある技術が別の技術より優れていることよりも「思慮深いコミュニケーション」が重要だった
「コミュニケーションと親切さ」が開発ツールの世界で重要な価値であることを強調している

2件のコメント

kmc0722 2024-03-13

知人が言っていた「顧客を説得するには孫の手にならなければならない」という言葉を思い出しますね

あまり鋭くある必要も、あまり速くある必要も、あまり快適である必要も、あまり高価である必要もなく、ただちょうど望むところをかいてあげられさえすれば、それが顧客の望むサービスなんだと（笑）

cosine20 2024-03-13

Git はリーナス・トーバルズが Linux のソースコードを管理するために作ったものなので、ある程度は妥協できない部分があったのだろうと思います。
締めくくりの考えの要旨が、まるで Git は Facebook 自身の要求を聞かず、コミュニケーションや親切さを重視しなかったので良くない、というふうに聞こえるのですが、私は単にいろいろな面で性向が互いに違っていただけだと思います。
逆に考えれば、Facebook には Git が推奨したリポジトリ分割を受け入れて実行する方法も残されていました。自分たちが望まない種類の親切さだっただけでしょう。