2

元のプロジェクトと同時に進化する新しいプロジェクトに複製したいプロジェクトがあります。

両方のプロジェクトの最終的な目標は異なりますが、将来の機能は共有されます。

2 つのブランチを持つ 1 つのリポジトリを保持すると、あまりにも多くの違いが生じるのではないかと心配しています。
プロジェクトを 2 つのリポジトリに分割した場合、それらの間で機能をマージするのがどれほど簡単かわかりません。

私が git を使ったのは過去 2 年間だけで、それをマスターしたかどうかはわかりません。

2 つのプロジェクトを進化させ、いくつかの機能を git と共有するにはどうすればよいですか?

4

1 に答える 1

2

これは Git とはほとんど関係ありません。どのソース管理ツールでも (ツールなしを含む)、これらと同じ組織の問題に直面するでしょう。これらの質問は答えるのが難しいため、解決しません。私はあなたのプロジェクトについてあなたに推薦するのに十分な知識はありませんが、いくつかの代替案を提供します. これらのオプションは相互に排他的ではありません。

  • 同じリポジトリ内の異なるブランチ- これは、同時に複製することを除いて、実質的に 2 つの異なるリポジトリを持っています。2 つのブランチをマージしても意味がないので、このように両方のプロジェクトのソースを一緒に保持する利点はありません。これをしないでください。
  • 1 つのリポジトリ。ビルド時に区別するmaster- 2 つのビルドを含む 1 つのブランチで1 つのリポジトリを保持します。プロジェクト A またはプロジェクト B を同じソースからビルドできます。ソースを共有するすべての機能は、文字通り同じファイルから構築されます。変更を行うときはいつでも、両方のビルドが引き続き機能すること、および一方のプロジェクトの変更が他方のプロジェクトに影響を与えないことを確認する必要があります。使用するプロジェクトは 1 つだけなので、バージョン管理、リリース、および分岐が容易になります。
  • 1 つのリポジトリ。実行時に区別する- 以前と同様に、2 つの個別のビルドの代わりに、1 つのビルド出力を生成する 1 つのビルドのみを使用します。機能は、実行時に有効または無効にすることができます。それらを別の製品として販売したくない場合は、メニュー、構成ファイル、またはライセンス スキームを介してこれを行うことができます。

  • 3 つのリポジトリ- 2 つの成果物と、それらが共有するいくつかの共通コードがあります。その共通コードを別のライブラリに分割し、それも維持します。次に、次のような依存関係グラフがあります。

    +-----------+    +-----------+
| Project A |    | Project B |
+-----------+    +-----------+
         \          /
          \        /
      +----------------+
      | Common Library |
      +----------------+

プロジェクト A とプロジェクト B はどちらも共通ライブラリに依存しています。この依存関係はさまざまな方法で管理できます (依存関係の管理は、それ自体が大きなトピックです)。共通ライブラリには、後でプロジェクト A とプロジェクト B のビルドで使用できるアーティファクトを公開するビルドを含めることができます。または、各プロジェクトのサブディレクトリにあるライブラリのソースを使用してビルドすることもできます。Git サブモジュールは、このアプローチに役立ちます。

于 2013-07-20T18:37:47.653 に答える