0

たぶん私は悪いワークフローを考えていますが、ここに行きます. すべてのプロジェクトが同じ構造を維持し、共通のクラスを共有しているため、他のプロジェクトのベースとして使用したいプロジェクトがあります。このようなベース プロジェクトは、2 つのブランチが存在する 独自の Git リポジトリ ( MyBaseRepoと呼びましょう) に格納されます。

  • プロジェクトの非常に簡素化されたバージョンを含む master 。
  • mybranchには、master に含まれるすべてのものと、より具体的なクラスが含まれます。

私がやりたいことは次のとおりです。

  • MyNewProject などの新しいプロジェクトを作成し、MyBaseRepoから 2 つのブランチの 1 つを複製します。
  • 新しいプロジェクトのオリジンとして、 新しいMyNewProjectRepo Git リポジトリを作成します。
  • MyNewProjectの実装に関連するすべての変更をMyNewProjectRepoにプッシュ/プルします。
  • MyBaseRepoが更新されたら、適切なブランチから変更をフェッチします 。

つまり、基本クラスが変更されたときに子プロジェクトが更新を取得できるように、ある種の「リポジトリ継承」を導入したいと考えています。

これまでのところ、必要に応じてMyBaseRepoをフェッチし、適切なMyBaseRepo/ブランチをMyNewProjectマスター (または任意の MyNewProjectブランチ) とマージすることで、ほぼ上記のことを行うことができます。これは適切な方法ですか、それとも私は自分の人生を必要以上に複雑にしていますか? 回答ありがとうございます。

4

1 に答える 1

0

あなたが問題を説明した方法（2つのブランチの部分を除く）だと思いますが、git submodulesを使用できます。これにより、プロジェクトのすべてのリビジョンがサブモジュールの特定のリビジョンにバインドされます。

の 2 つのブランチが本当に必要な場合はMyBaseRepo、次のようにします。

  • 空のレポを初期化します。

$ git init

  • コミットして初期化するmaster

  • リモート MyBaseRepo を新しいリポジトリに追加します。

$ git remote add MyBaseRepo the_repo_location $ git fetch MyBaseRepo

  • 次に、必要に応じてマージします。

$ git merge MyBaseRepo/master

また

$ git merge MyBaseRepo/mybranch.

しかし、私はサブモジュールを使用します。これは「よりクリーンな」ソリューションです。リモート ブランチからマージする代わりに、サブモジュールを更新するだけで済みます。

于 2013-09-12T22:06:38.577 に答える