結論としては...社内専用システムを用意したりする余裕のない組織、ガバナンスの弱い組織、強い技術リードがいない組織は、単一レポは難しそう...
コラム - グーグルのクラウドを支えるテクノロジー | 第20回 Googleのソースコード管理システム ― Piper/CitC｜CTC教育サービス 研修/トレーニング
Googleのソフトウェア開発では、単一のリポジトリを使用することに加えて、トランクベースの開発を行うという特徴があります。ここでいうトランクは、Gitにおけるマスターブランチに相当するものです。一般に、Gitを使った開発では、機能ごとに開発用のブランチを作成して、開発ブランチ上で複数のコミットを行った後、最後に、開発ブランチの内容をマスターブランチにまとめて反映します。一方、Googleでは、そのような事は行いません。基本的にすべての修正は、トランク（マスターブランチ）に直接に反映されます。
特に、新機能を追加する際は、機能追加前と追加後の両方のコードをソースコード内に残しておき、設定ファイルのフラグによって、新機能の有効化／無効化を指定できるようにしておきます。これには、新機能に問題が発見されて、一時的に以前の状態に戻したいという際に、古いソースコードから再ビルドするのではなく、設定ファイルの変更だけで機能を無効化できるというメリットがあります。この手法は、一部のユーザーのみに機能を有効化して行う、A/Bテストなどにも利用されています。
ひとつのリポジトリですべてのプロジェクトを管理する｜こんぴゅ｜note
GoogleやFacebookなどの超巨大で複雑なコードベースを持つ組織では、大量のリポジトリを作るより、ひとつの巨大リポジトリに集約して集中管理した方がうまくいくと判断し、実際にそうしている。
たとえば、あるAPIの仕様を変更したいと思ったら、そのAPIに依存しているリポジトリを正確に洗い出して一つ一つリポジトリを更新していかないといけない。そのリポジトリの数が数個でもげんなりだが、Googleクラスだとシャレにならない数になり膨大な作業が発生する。集中管理した場合まとめて一気に変更できる。
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 － Publickey
デベロッパーは社内のすべてのコードを自分たちのツールで触ることができるため、必要なライブラリや関数を見つけやすい。
コンパイラチームでは、社内の最新コードを使ってコンパイルやコード生成を試すことができる。
古いAPIを自信を持って削除できる
死蔵されているコードを見つけ、削除するツールを利用して、コードの健全性を高めている
Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi
巨大レポジトリにはいろいろメリットがあるが、一番大きいのは「呼び出し側のコードをまとめて変更できる」ことだと思う
技術的負債の例えをつかうと、Google の巨大レポジトリとブランチ無し運用は、ある種の無借金経営といえると思う。依存しているライブラリのバージョン固定や、レポジトリのブランチで得られる安定性は、借金なのだ。ほとんどの場合、ライブラリはいつかアップグレードしなくてはいけないし、ブランチはいつかマージしなくてはいけない。払わなくてはいけない利子は時間がたつにつれて増えていく。そう考えると、Google の一見すると変な、分割統治の逆をいくようなやり方にも、それなりに利点はあるように思う。
- korfuri/awesome-monorepo: A curated list of awesome Monorepo tools, software and architectures.
- Monorepos: Please don’t! – Matt Klein – Medium
- Monorepos in the Wild – Markus Oberlehner – Medium
4. Sphinxでの文章の書き方(reStructuredText) — study sphinx 1 documentation