4

私は大規模な .NET ベースのプロジェクトを持っており、それぞれが大規模システム内の異なるモジュールを表す 20 以上の異なるソリューションを使用しています。各ソリューション内には、多数のプロジェクトがあります。

私たちは現在、すべてのソリューションを 1 つの Git リポジトリで処理しています。それらは一種のものであり、これまでのところ問題なく機能しています。ただし、CIサーバーを使用して、たとえばビルドと変更のテストを開始したいと考えています。ただし、これは毛むくじゃらになり始めるところです。CI サーバーに完全なソリューションを構築させることはできませんが、変更されたコンポーネントを構築するだけです。SVN では、1 つのレポでこれを実現し、CI サーバーのさまざまな構成を制限してさまざまなパスをリッスンすることができました。たとえば、「src/ModuleA」は 1 つのビルドと構成であり、「src/ModuleB」は別の構成でした。

Git でのオプションは何ですか? また、ベスト プラクティスと見なされるものは何ですか? それらの長所と短所は何でしょうか? 答えの一部として、同様のセットアップを備えたより大きなオープンソースソリューションを指摘していただければ幸いです。

  1. 各モジュールを独自のレポに入れることができると思いますか? しかし、GitHubなどでのホスティングに関しては問題があり、レポで請求されるため...そうでなければ、これが最良の選択肢でしょうか?
  2. Git サブモジュールは機能しますか? これはサブモジュールの正しい使い方ですか?
  3. このシナリオに役立つ CI 製品の他のオプションを知っていますか?
4

3 に答える 3

2

各モジュールを独自のレポに入れることができると思いますか? しかし、GitHubなどでのホスティングに関しては問題があり、レポで請求されるため...そうでなければ、これが最良の選択肢でしょうか?

これらのモジュールが相互に依存しすぎていない限り、これは最良の選択肢のままです。これは、分岐を管理する際に追加のハードルを意味することを意味します (すべてのモジュールのすべてまたはほとんどを同時に分岐することを覚えておく必要があるため、マージバックの場合と同じです)。

課金が問題になる場合は、BitBucket リポジトリで同様の組織を持つことができることを覚えておいてください (小さなチームではありますが、無料 のプライベートリポジトリを提供しています)。

各モジュールを独自の git リポジトリに配置したら、「git サブモジュールまたはサブツリーのマージ メソッドを除く git リポジトリ内の子プロジェクトで成長しているベース プロジェクトを結合する」で説明するように、それらをサブツリーまたはサブモジュールと結合できます。
git slaveは、より単純な代替手段にもなります。

于 2013-02-03T18:30:17.303 に答える