何百人もの開発者が単一のソリューションに取り組んでいるときの開発方法論？
私たちは、特定の日にリリースされる予定の1つの製品（リビジョンコントロールGitを使用）に継続的に取り組んでいる約200人の開発者で構成される組織です。
開発者の数が非常に多いため、各チームに約10人の開発者がいる「機能横断型」のチームを作ろうとしているため、組織には約20人の開発チームがいます。
メインリポジトリで製品の継続的に「高水準」（開発者がプルを行う場合、製品は少なくともコンパイル可能である必要があるなど）を維持したいので、ある種の品質ゲートを使用します。
質問の言い方が少しわかりませんが、単一の製品に取り組んでいるそのような大規模な開発者グループの開発方法論についてアドバイスが得られるかどうか疑問に思っています。
私たちの意見では、スペクトルの一端は、各開発者がメインリポジトリに直接コミットできるようにすることですが、開発者/コミットの数が多いため、「メインリポジトリ」が常に壊れた段階にある可能性があるため、コミットごとに要求の厳しい「品質ゲート」を持つことはできません。
スペクトルのもう一方の端は（Linus Torvalds/Linuxがそれを行うと思います）ツリーまたはピラミッド構造のようになる可能性があります。「メインリポジトリ」には3つのプルソースしかなく、これら3つには信頼できるプルソースがほんの一握りしかありません。しかし、そのような構造では、「メインリポジトリ」に到達するために、変更が上昇するまでの長いチェーンを持っていると感じます。さらに、マージの競合が発生した場合、問題は「元の開発者」以外の別の開発者にあります。
このすべての背景情報と意見を述べた上で、非常に多くの開発者に推奨される開発方法をどのように学習して読むことができますか？大規模な組織（Microsoft、Facebook、Ubuntuなど）はどのようにして開発を構成していますか？
あなたは確かに検討する必要があります製品をモジュールに分割するインターフェースチームがそれらの構成モジュールを製品にまとめる。これは、リポジトリを分割してモジュールのパーティション分割と階層に一致させることを意味します。あなたがこれを行うことができないように見える場合、プロジェクトはおそらく、貢献している開発者の数を考慮して、マージによって引き起こされた停止に取りかかるでしょう。
バージョン管理にGitを使用することを計画している場合は、透明性を向上させ、各リポジトリの品質を確保するためにコードレビューシステムを使用（ Gerrit など）をお勧めします。そうすれば、すべての作業を信頼できるリポジトリにマージする前に承認する必要があります。このシナリオでは、特定の信頼できる個人に、コードレビューシステムの下のリポジトリから別のリポジトリ（おそらくコードレビューシステムの下）にプッシュするためのアクセス許可を付与することは理にかなっています。これを正しく使用すれば、開発プロセスを妨げない、高速で非常に有益なプロセスになるはずです。
ビルドの検証については、継続的インテグレーション（CI）サーバーが必要です。その目的は、コードを自動的にビルドして検証することです。コードを検証するとは、コードが正常にコンパイルされ、テストに合格することを意味します。 Infact Jenkins （CIサーバー）は Gerrit コードレビューシステムに Gerrit 検証ステージの一部としてリンクでき、プロセスを完全に自動化できます。
これらの統合ツールに加えて、時間のマージを最小限に抑えるために、開発方法論の一部として頻繁な統合に努めることが重要です。
それは価値があるかもしれませんScrumのようなアジャイル開発プロセスを考えると、その目的は、複雑な製品を扱いやすい製品の増分（スプリントと呼ばれます）に分割することです。これらはリポジトリ間の統合の機会を提供します。
明らかに、200人の開発チームでは、ある種の階層構造が必要です。個人または少人数のグループがソフトウェア製品の設計について決定を下しています。開発プロセスはこれを反映する必要があります。作成されるソフトウェアが実際に作成したいものと一致することを確認するために（そして品質向上のために）コードレビューとテストが必要です。
小さなチームでさえ、チームを導き、個々のコンポーネントを開発する際に彼らの仕事をレビューするリーダーが必要です。彼らはまた、チームレベルで実施されている品質管理プロセスであるべきです。
したがって、はい、リポジトリに関しては階層構造に従う必要があります。これは、プロジェクト全体の階層構造を一致させるためです。
個々のコンポーネントを組み立てて、それらをすべてまとめることを考える前に、ある程度の妥当性までテストする必要があります。 200人がメインプロジェクトに直接コミットすることを許可することは混乱を招くでしょう。プロジェクトのメインビルドに影響を与えることなく、個人が日常的に変更をコミットできるグループごとに個別の領域を用意する必要があります。
「メインリポジトリに到達するために、変更が長いチェーンを登る場合」は、このチェーンによって品質を確保できるため、非常に良いことです。すべての変更がメインリポジトリにすぐに適用されると、seem高速になる可能性がありますが、実際には、ソフトウェアのバグが多く、使用できないメインビルドがあるため、これは大きな頭痛の種になります。
「マージの競合が発生した場合、問題は別の開発者にある」ことも良いことです。具体的には、より高いレベルの開発者が競合の解決方法を決定する必要があります。
何か大きなものがあり（結果として）管理できない場合、解決策は、それをより小さく管理しやすい部分に分割することです。
チームとプロジェクトをよりよく維持するのに役立ついくつかのステップがあります。
機能をモジュールに分割します。機能性は、高い凝集性、低いカップリング、および依存性の逆転の原理を使用して、独立した最大限のモジュールに分割する必要があります。最初の原則は、論理的に一貫したモジュールを作成するのに役立ちます。 2つ目は、これらのモジュールをできるだけ独立させるのに役立ちます。 3番目のものは、依存するモジュールを同時に開発するのに役立ちます（モジュールAがモジュールBに依存している場合、Bは、Bが完全に準備ができていなくても、Aが使用できるインターフェースを提供する必要があります）。
明確なドキュメントがあります。多くの人が一緒に作業していると、物事は簡単に忘れられたり、誤解されたりすることがあります。したがって、要件から建築ソリューションまで、すべてのドキュメントに特別な注意を払う必要があります。
タスク用の人（人用のタスクはありません）。機能を小さなセットに分割した後、これらのセットで作業するチームを作成します。この段階では、チームの作成がより簡単になります。これは、各チームの作業内容をすでに知っているためです。また、コードレビューなどのタスクは各チーム内で行われます。
タスクの明確なシステム。 200名の開発者はそれぞれ、何に取り組むべきかを明確に知っている必要があります。これにより、すでに何が行われたか、一人一人が何に取り組んでいるか、残りの作業量を追跡できます。
ソース管理。 （これは他の回答でかなりうまく概説されていると思います）））
そして最後に、できるだけ単純なチームとモジュールの構造を作成するようにしてください。このような巨大なプロジェクトでは、複雑さを許容できません。
階層構造を示唆する他の回答に加えて、これは、「統合」の時点をスケジュールする必要があることを意味します。これは、テストとバグ修正以外の作業が行われない最終段階の小規模なプロジェクトとそれほど変わりません。あなたが高い基準を求めて努力している大規模なグループで働いているので、そのほとんど（心構え）はおそらくすでに整っているでしょう。
Hotpotatoの回答（IMHOに直接マークされています）に加えて、ソースコントロールゲートを実装することをお勧めします。大規模なチームとコードベースをSCMのgitに移動したとき、私たちはあなたが説明したモデルと同様に、「慈悲深い独裁者」メソッドと呼ばれる方法を使用することにしました。
このシナリオでは、ソースブランチから定期的に更新される完全なコードベースのさまざまなブランチが多数ありますが、コードをより目に見える/パブリックエリアに昇格させる責任は1人（または小さなグループ）にあり、通常はコードレビュープロセスに関連付けられています。よく整理された分岐構造を使用すると、これは非常にうまく機能します。詳しくは、 このリンク をご覧ください。
私は数百人の開発者が約1億5,000万のSLOCと同時に作業している巨大なシステムに取り組んできました。これはメインフレーム上にあったので、Visual Studioについては話していませんが、原則は引き続き採用できます。
まず、Javaを使用している場合は、Mavenを使用することをお勧めします。 VSを使用している場合は、Nugetを使用することもできますが、Mavenにまだあるかどうかはまだわかりません（多少異なります）。このようなシステムを使用すると、依存関係をプルして、個別に機能させることができます。ビルドスクリプトで関連する依存関係をプルし、バッチとしてビルドします。
あなたが直接質問をするのではなく、方法論を要求しているとすれば、前の雇用主がそれをどのように処理したかをお話しします。
システムはclustersに分割されました。クラスタは、ビジネス領域とシステムインフラストラクチャ領域を表しています。私はそれらに名前を付けるつもりはありませんが、巨大な小売ビジネスの場合、マーケティング、小売業務、オンライン業務、調達、流通などのことを考えることができます。システムインフラストラクチャは、顧客やセキュリティなどを表しています。各クラスター内にはcomponentsがありました。前の例えを使用すると、たとえば、シングルサインオン、ディレクトリサービス、監査、レポートなど、セキュリティのコンポーネントを検討できます。各コンポーネントには、関連するルーチンが格納されていました。
名前空間またはパッケージとして、たとえば、Organization.Security.DirectoryServicesがあります。関連する領域のすべてのロジックを含めることにより、チームはかなり自律的に作業しました。複数のチームからの入力を必要とする明らかに大規模なプロジェクトが発生しましたが、それらは主にスムーズな運用でした。
これがお役に立てば幸いです。