Visual Studioで簡単にプロジェクトを再利用できるようにgitリポジトリを設定するには

Question

私の問題は、例を用いて最もよく説明されています。

プロジェクト「A」があるとします。

「A」に依存するプロジェクト「B」もあります。

別のプロジェクト "C"も "A"に依存します。

私の "メイン"プロジェクトは "B"と "C"に依存しています。 「A」に直接依存することもあります。

"メイン" == "D"

これらは私の要件にしているときビット"dreaded diamond of inheritance"次のようになります。

• 私が編集できるようにしたいと思います"メイン"のソリューションのプロジェクト "A"、 "B"、 "C"の内容と変更の提出（DLLだけでなくコードも含めたい）しかし、 "B"と "C"はどちらも "A"に依存しているため、同じコミットを参照するように強制する必要があります。

• プロジェクト "A"、 "B"、 "C"は他のプロジェクトからも参照される可能性が高いので、プロジェクト "main"の作業ディレクトリの所有権を引き継ぐことはできません。

• また、各プロジェクトのリポジトリを外部レポジトリと同期させることも可能です。

• プロジェクト「A」、「メイン」、「B」、「C」とは、あるべき

どのように私はこれを達成するために、私のリポジトリを設定する必要がありますか？ submodules approachを使用して

Answer 1

、私の代わりに、依存関係の階層の、依存関係のリストを含むモデルをお勧めします：

がでます「git submodule add」「parent」レポ、サブモジュールを作成します。

parent 
    D 
    C 
    B 
    A 

任意のシンボリックリンクを追加します（：D、C、BとAため）、各プロジェクトをコンパイルする必要があります（つまり、自分の構造内から依存関係のソースを見つけることを意味します）。

"parent"レポは、プロジェクトが親リポジトリの履歴の特定の時刻にコンパイル/実行するために必要な正確なバージョンで、各依存関係を表すSHA1の正確なリストを参照します。

そして、私は「true nature of submodules」で説明として、あなたはA、B、CまたはDにしたい任意の修正を行い、それぞれのupstream repoにプッシュすることができます。
parentリポジトリに戻り、依存リポジトリA,B、C、およびDの新しい状態を表すSHA1の変更を追加してコミットすることを忘れないでください。

これは、任意の重複依存関係を解決することの利点を持っているcomponent approach、次のとおりです。BとCがAの異なるバージョンが必要な場合は、parentレポはAの1つだけのバージョンを選択することがあります。

はOPオヌルの答えに追加するには：

依存関係は必ずしも相対

でなければなりません：それは固定パスで別のを確認する必要がある場合は、サブモジュール内のシンボリックリンクを追加することができます。

どのように私は自動的例えば、ライブラリの正しいセットをチェックアウトするか、「user」リポジトリ

を作成します。

上記のセットアップではAとB君はAとBのためのバージョンを起動する有効なを決定したら、「親」のコンテキストでその使用のための専用のブランチを作成してプッシュすることができます。
make those submodule follow that branchは、git submodule update --remoteのサブスロットAとB専用ブランチの最新のSHA1をチェックアウトします。

Answer 2

ちょうど私があなたのアプローチを理解していることを確認するために：私は、ライブラリのリポジトリを設定するために必要

もの：

1. 各ライブラリのためのサブモジュールを作成し、「親」のリポジトリ
2. を作成します。
3. 依存関係は相対的でなければならない、すなわちDがBに依存している場合、パスは../../B/someフォルダのようになります
4. 各親リポジトリにコミットのvalを表し私は新しいプロジェクトにライブラリの選択したセットを含めるために必要図書館

物事のIDの組み合わせ：

1. は、それぞれ必要なライブラリにブランチを作成し、「ユーザー」リポジトリ
2. を作成します。リポジトリ（例： AとB）を "for_user"のようにし、これを "user"プロジェクトのサブモジュールのために追跡します。
3. 使用したライブラリの変更を追跡する「親」リポジトリに「from_user」ブランチを作成します（ブランチベースごとにリポジトリブランチを追跡できるかどうかは？）。
4. 選択したライブラリセットを含めます（例： AとBを "for_user"ブランチから削除します。
5. Aおよび/またはBで行われた変更は、このブランチに移動し、これらのライブラリを使用する他のプロジェクトの他の "from _..."ブランチにマージされると、 "親"マスターブランチにマージされます。 「親」プロジェクトは、一貫性のあるライブラリセットを作成するために使用されます。

効果的に、これは「のために_...」それぞれの「親」リポジトリとブランチで「_...から」これらのライブラリを使用するすべての「ユーザー」プロジェクトは、分岐によって表される意味使用されたライブラリリポジトリ。どのように私は自動的例えば、ライブラリの正しいセットをチェックアウトするん

• ：

  セットアップは次のように

  A 
      branch "for_user" 
      branch "master" (== for_parent) 
      <other branches for each project using this library> 
  
  B,C,D 
      <like A> 
  
  
  parent 
      submodule A - tracks branch dependent on the current branch 
      submodule B - tracks branch dependent on the current branch 
      <other submodules> 
      branch "master" (== from_parent) 
      branch "from_user" 
      <other branches for each project using one of the libraries> 
  
  user 
      <own stuff> 
      submodule A - tracks branch "for_user" 
      submodule B - tracks branch "for_user" 
  

  オープンな質問になります上記の設定でAとB？私はすべての利用可能なライブラリをチェックアウトすることができ、それは何らかの形で（AB）は、このためにgitのか、いずれかのバージョン管理システムを使用しないでください、各ライブラリ

Answer 3

に別々のサブモジュールの必要性を排除するであろう。

NuGetを使用してください。

他のプロジェクトを直接含める必要はありません。代わりに、すべての依存関係を.nugetパッケージにまとめて、それを依存関係の処理に使用します。サブモジュールは問題の解決策に見えますが、実際には、他のプロジェクトを単に組み込むのではなく、適切な依存関係管理を使用するほうがはるかに優れています。

TeamCityなどのCIシステム、さらにはTFSを使用すると、自動的に新しいナゲットパッケージを構築でき、TeamCityはナゲットサーバーとしても機能します。

「本当の」NuGetサーバーを使いたくない場合は、イントラネットのどこかで共有ドライブを使用することもできます。