[解決済み] 複数プロジェクトが存在するサーバーのGITリポジトリレイアウト

質問

私が Subversion をセットアップする方法について気に入っていることのひとつは、複数のプロジェクトで単一のメインリポジトリを持つことができることです。あるプロジェクトで作業したいとき、そのプロジェクトだけをチェックアウトすることができます。このように

\main
    \ProductA
    \ProductB
    \Shared

では

svn checkout http://.../main/ProductA

gitの新しいユーザーとして、私は特定のワークフローにコミットする前に、この分野のベストプラクティスを少し探したいと思っています。これまで読んだ限りでは、git はプロジェクトツリーのルートにある単一の .git フォルダにすべてを保存します。ですから、私は2つのことのうちの1つを行うことができました。

1. 製品ごとに個別のプロジェクトをセットアップする。
2. 1つの巨大なプロジェクトを設定し、サブフォルダに製品を格納します。

製品間に依存関係があるので、単一の巨大なプロジェクトが適切だと思われます。すべての開発者がコードを共有できるサーバーを使用する予定です。私はすでにこれを SSH & HTTP で動作させており、その部分は気に入っています。しかし、SVN のリポジトリはすでに何 GB もあるため、各マシンにリポジトリ全体をドラッグするのは悪い考えのように思われます - 特に、過剰なネットワーク帯域幅を請求されるためです。

Linux カーネルプロジェクトのリポジトリも同様に大きいので、Git でこれを扱う適切な方法があるはずですが、私はまだそれを見つけ出していません。

非常に大きなマルチプロジェクト・リポジトリを扱うためのガイドラインやベストプラクティスはあるのでしょうか？

どのように解決するのですか?

ガイドラインは簡単で、以下の通りです。 Git の制限 :

• 1つのプロジェクトに1つのレポ
• メインプロジェクトに サブモジュール .

アイデアは すべてを を一つの巨大な git リポジトリに保存するのではなく、メインプロジェクトとして小さなリポジトリを構築し、他のリポジトリの正しいコミットを参照し、それぞれがプロジェクトまたはそれ自身の共通のコンポーネントを表すようにすることです。

は OP ポール・アレクサンダー コメント :

これは subversion が提供する "externals" のサポートに似ているように思えます。

私たちはこれを試してみましたが、プロジェクトが互いに依存しながら同時に開発されているため、externals のバージョン参照を常に更新することは非常に面倒であることがわかりました。他のオプションはありますか？

@Paul: はい、メインプロジェクトからバージョンを更新する代わりに、次のいずれかを行います。

• メイン プロジェクトから直接サブプロジェクトを開発する (" で説明されているように)。 サブモジュールの真の姿 "で説明しています)。
• または、サブレポの中で origin を参照し、別の場所で開発されている同じサブレポに移動します。そこから、別の場所で行われた変更をそのサブレポからプルするだけです。

どちらの場合でも、新しい設定を記録するために、メイン プロジェクトをコミットすることを忘れてはいけません。ここで更新するための "external" プロパティはありません。すべてのプロセスははるかに自然です。

正直なところ、これは本当に面倒なことのようで、開発者が毎回手動で何かをする必要があるものは、バグやメンテナンスの定期的なソースになりそうです。

スーパープロジェクトでいくつかのスクリプトを使用して、これを自動化することを検討すると思います。

と返信しておきました。

正直なところ、あなたは正しかったかもしれません...それは、最新の Git リリース 1.7.1 .

git diff そして git status は、たとえメインプロジェクトから実行されたとしても、 サブモジュールの状態を考慮することを学びました。

サブモジュールの変更を見逃すことはできないのです。

とは言うものの

• サブモジュールは SVN 外部モジュールとは異なります: " を参照してください。 なぜgitサブモジュールはsvnエクスターナルと互換性がないのですか？ を参照してください。
• サブモジュールの管理は厄介です: " を参照してください。 git サブモジュールはどのように動作するのですか？ をご覧ください。