ブランチまたはフォルダーを使用してこれを回避できますが、サブモジュールの最有力候補の IMO です。私はそれらをそのようなものに使用します。3 つのリポジトリのセットの例を次に示します。
common/ (bare repo of common files)
.git/
wp7/ (regular repo of wp7 specifics)
.git/
common/ (submodule)
wp8/ (same as wp7, but for wp8)
.git/
common/ (submodule)
一般的なものを作成するには、通常のレポとgit clone --bare repo optional_bare_repo_name
. 名前を付けないと、ベア バージョンであるcommon
というフォルダにクローンされます。common.git
これで、いずれかの wp repo 内から実行できますgit subdmodule add path/to/common optional_folder_name
(指定しない場合は repo フォルダー名が使用されます)。これにより、共通リポジトリが各 wp リポジトリ内のフォルダーに効果的にクローンされます。これらは、単一のレポのブランチにすることもできます。各ブランチでサブモジュールの追加を行うだけです。
サブモジュールはブランチよりもメンテナンスが少し多いですが、ブランチではできないことを行います。それらは、レポ内で開発の平行線を提供します。いずれかの wp リポジトリ内の共通リポジトリに変更を加えた場合は、そこでコミットし、それを外部のベア バージョンの共通リポジトリにプッシュして戻し、他の wp リポジトリの共通リポジトリにプルダウンすることができます。これは単なる通常のリポジトリですが、そのクローンは wp リポジトリ内に存在します。あなたの wp リポジトリでは、最初に共通リポジトリ内の正しいコミットをチェックアウトし、次に wp リポジトリの外で実行しgit add common
、git commit -m'Update common for feature X'
. これにより、コミットのハッシュを共通サブモジュールに保存するだけの wp リポジトリにコミットが作成されます。
後で wp リポジトリでこのコミットをチェックアウトすると、wp コードがチェックアウトされ、共通リポジトリで適切なコミットもチェックアウトされます。基本的に、特定の時点での共通リポジトリのバージョンを追跡できます。これにはいくつかの理由があります。1 つには、特定の wp リポジトリで最新のものを入手したくない、または必要としない場合は、最新のものを入手する必要はありません。また、どちらかの共通リポジトリで古いコミットを実際にチェックアウトして追加し、その wp リポジトリでコミットしてから、必要な限りその古いコミットに対して作業できることも意味します。ただし、もう少し作業が必要です。wp と共通リポジトリを一緒に作業することを忘れないでください。私は毎日やっていますが、多くの人が面倒だと言っていると聞きました。
また、特定のバージョンの common をファイルと共に wp リポジトリに追加してコミットすることもできます。たとえば、一般的なものにアクセスしてリファクタリングし、ホップアウトして wp7 のリファクタリングに対する変更を修正してから、common を追加して wp7 の変更を行うことができます。 wp7 でまとめてコミットし、両方の変更を追跡します。1 つのコミットをロールバックすると、共通リポジトリもリファクタリングの前にロールバックされるため、すべてのコミットで適切に機能するコードを使用できます。