2

いくつかの子プロジェクトがあります: 「プロジェクト 1」、「プロジェクト 2」など、将来的には。

また、「ベースプロジェクト」という名前のプロジェクトがあり、他のプロジェクトの基盤となっています。「ベース プロジェクト」は、コンテンツ管理システム (CMS) です。

すべてのプロジェクトには、独自の git リポジトリがあります。

「Project 1」「project 2」などは「ベースプロジェクト」を利用して開発・成長していきます。

submodule や subtreemerge のような git のメソッドがいくつかあります。しかし、ここには収まらないようです。「ベース プロジェクト」は、サブ ディレクトリに複製しないでください。ルートディレクトリにあります。「プロジェクト1」や「プロジェクト2」で成長している…

子プロジェクトで作業するときは、「ベース プロジェクト」の変更を個別にプッシュして、他の子を取得する独自のリポジトリにできる必要があります。

私に何ができる？

4

1 に答える 1

3

サブツリー マージまたはサブモジュールは、コンポーネント ベースの開発用です。2 つの異なるが一貫したファイル セットを組み合わせたものです。
ファイルの各セットは、個別に分岐またはラベル付け (サブモジュール) することも、一緒に (サブツリー マージ、独自の履歴を取得する機能を維持しながら) することもできるため、独自のディレクトリにあります。
ただし、どちらも別のディレクトリが必要です。

しかし、あなたが説明しているのは (" " はルート ディレクトリにあり、" " または " "Base Projectで成長しています)、システム ベースのアプローチに関するものです。すべてのコンポーネントが 1 つの大きなコンポーネントにマージされます。単位。 したがって、プロジェクトごとに 1 つのブランチ ( for 、forなど) を持つことができます。project 1project 2
branch1CMS-projet1branch2CMS-project2

projectxただし、固有の変更または CMS 固有の変更を元の (および別の) リポジトリに報告する必要がある場合は、専用のブランチで特定の変更を行い、それらの変更を結合します。

  • branchp1影響を与える変更のためのものですproject1
  • branchc1影響を与える変更のためのものですCMS
  • branch1branchp1fromとのマージの結果になります。branchc1

( も同様branch2)

その後、これらの変更をパッチとしてエクスポートできます。

  • からレポbranchp1へproject1
  • からレポbranchc1へCMS

不便なのは、元のリポジトリに既にマージされたものを Git が記憶しないことですが、これにより、CMS-projectx一連のファイルで作成された共通の履歴を元CMSのリポジトリに戻してレポートすることができますprojectx。

注: 2 つの余分なブランチを管理したくない場合、別の解決策は次のとおりです。

  • 各コミットには、CMS の変更またはプロジェクトの変更のみが含まれていることを確認してください
  • それらを区別するのに役立つコミット メッセージを残します (" [CMS] my CMS modification comment..."、または " [Project1] my project1 modification comment..."
  • スクリプトgit-extract-patchesを使用して、適切なコミットのみをパッチとしてエクスポートします。
于 2012-11-25T12:49:08.690 に答える