11

次のプロジェクト設定があります。

  • Solution A
    • Project 1(軽量コンポーネント)
    • Project 2（多くのファイルが含まれており、に依存していますProject 1）

Solution A単一のgitリポジトリです。次に、別のソリューションを作成したところ、 の機能を再利用したり、更新したりできることがわかりましたProject 1。したがって、私の2番目のソリューションはおそらく次のようになります。

  • Solution B
    • Project 1（共有する必要があります！）
    • Project 3(によって異なりますProject 1)。

Project 1今、私は共有コンポーネントになりたいと思っています。Project 1つまり、いずれかのソリューション (Aまたは)のソース コードを変更するたびに、Bそれに応じてもう一方を更新する必要があります。

たぶん、これはgitのサブモジュール機能に何か関係があります。ただし、それを使用できた唯一の方法は、全体を のサブモジュールとして指定することです。の巨大なサイズのため、これは私が理想的に望んでいるものではありません。サブモジュールにするために必要なのは、そのごく一部だけです。Solution ASolution BSolution A

svnで可能であり、説明したとおりに機能することはわかっています。プロパティで外部リポジトリ内のディレクトリを指定しsvn:externalsます。

それに関するヒントはありますか？それとも、私は何かが欠けていますか？

4

2 に答える 2

8

これは間違いなくサブモジュールに関連しています (サブモジュールの性質を参照してください)

あなたの場合、理想的な解決策はGit リポジトリから抽出することです: Project1gitサブディレクトリを抽出し、そこからサブモジュールを作成する方法を 参照してください。.SolutionA

ただし、SolutionA の履歴を書き換える必要があるため、既に公開しており、一部の人がそこから引っ張ってきた場合、これは問題になります。

抽出プロセスにfilter-branchを使用します。

プロジェクトのルートであるかのように見えるようにリポジトリを書き換え、Project1/ 他のすべての履歴を破棄するには:

git filter-branch --subdirectory-filter Project1 -- --all

したがって、たとえば、ライブラリのサブディレクトリを独自のリポジトリに変えることができます。オプションをリビジョン オプションから--分離する と、すべてのブランチとタグを書き換えるに注意してください。filter-branch--all

Project1次に、サブモジュールとして宣言しSolutionBます。

cd SolutionB
git submodule add /path/to/Project1 Project1

SolutionB注: !を公開する予定がある場合は、ここでローカル URL を使用しないでください。

git commit -m "Add submodules Project1"
于 2010-02-24T13:35:22.113 に答える
0

プロジェクト 1 を独自のリポジトリに分割し、ソリューション A とソリューション B の両方のサブモジュールにします。

于 2010-02-24T13:34:04.213 に答える