現在、約 50 人のアクティブな開発者によって共有されている約 600 MB (.git ディレクトリのサイズ) の単一の git リポジトリを使用しています。
私たちのコードベースと開発者ベースが成長するにつれて、このアプローチは最終的にはコード量の増加 (遅い git ステータス) とプッシュ量 (他の誰かがその間にプッシュしたためにマスターへのプッシュが拒否される) のために持続不可能になるようです.
私の質問は、(1) コードの量に関して、現在のソリューションがどれだけうまくスケーリングできると期待できるかということです。(2) アクティブな開発者の数は?
単一の共通履歴を犠牲にすることなく、git のスケーリングを支援できる git の使用方法 (機能ブランチの多用など) または特定のテクノロジーはありますか?
ありがとう！
多数のユーザーに問題はありません。証拠は、Linuxがgitの下にあることです。
しかし、リポジトリのサイズは、多くのVCSのこの重要なルールを尊重していないのではないかと思います。バイナリをリポジトリに入れないでください。バイナリファイルの違いを効率的に計算できないため、リポジトリが急速に大きくなります。
いくつかの大きな変化する要素のネイティブソース形式がバイナリ（多くの場合、いくつかのドキュメントまたはメディア）である場合、サイズに問題がある場合は、おそらくその部分をVCSから管理する必要があります。
また、gitは実際の作業方法を定義していないことにも注意してください。すべてのコーダーが同じリポジトリと同じブランチに直接プッシュする場合は、問題があります。一部のコードマネージャーが変更をフェッチして中央リポジトリにプッシュする場合、問題はありません。gitは分散型VCSであることを忘れないでください。
Git は、Linux カーネルの開発を処理するためにLinus Torvaldsによって明示的に作成されました。これには、プロジェクトに貢献しているユーザーの数と、それによって作成されたコミットの量が考慮されます。
このようなサイズのプロジェクトが簡単に維持できるかどうかは、ワークフローに大きく依存します。誰もが使用するいくつかの開発ブランチのみを使用する場合、複数のマージ競合が発生する可能性があります。一方、開発が (feature) ブランチで高度に分離されている場合、そのようなブランチでの作業が完了し、作業がマージされるときにメインラインに触れるだけでよいため、メンテナンスがはるかに簡単になります。多くの場合、まさにそれに集中するために、特別なインテグレーターの役割を持つ人々がいます。Linux カーネルの場合、副官が開発者からコミットを収集 (および検証) し、それを独裁者(Linus 自身) に提示します。
全体としては、Git 内で巨大なプロジェクトを作成することを妨げるものは何もありません。状況によっては、可能であれば分割する価値があるかもしれません (多数の小さなリポジトリを持つAndroid の OSPと比較してください)。
リポジトリのサイズが大きくても、最初のクローン作成プロセス以外のワークフローには影響しないことに注意してください。途方もなく大きな作業ディレクトリ (ソース管理システムに影響を与える) がない限り、 Git の通常の速度には影響しません。すべてのコマンドはローカルで実行さgit statusれ、作業ディレクトリ、インデックス、および現在のバージョンを確認するだけで済みます。つまり、履歴が長くても変更されません。Git のデータ モデルは有向非巡回グラフであるため、使用するアクセサー (ブランチ ポインター、HEAD など) を超えるグラフの大きさに関係なく、必要なもののほとんどがすぐに得られます。
そうは言っても、リポジトリの 600 MB は本当に多すぎます。多くのバイナリ ファイルが含まれていると思われますが、これは最善の方法ではない可能性があります。Git はバイナリ ファイルをテキスト ファイルと同じ方法で処理しますが、圧縮 Git は処理しません。また、すべての Git オブジェクトに適用されるデフォルトの gzip 圧縮は、多くの場合、バイナリ ファイル (既に圧縮されている画像など) にも役立ちません。そのため、可能であれば、アセットの別のソリューションを検討することをお勧めします。