複数のプロジェクトを持つサーバーのGITリポジトリレイアウト

Subversionの設定方法で気に入っている点の1つは、複数のプロジェクトを持つ単一のメインリポジトリを持つことができることです。プロジェクトに取り組みたいときは、そのプロジェクトだけをチェックアウトできます。このような

\main
    \ProductA
    \ProductB
    \Shared

その後

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

gitの新規ユーザーとして、特定のワークフローに取り組む前に、現場でのベストプラクティスを少し探りたいと思います。これまで読んだことから、g​​itはすべてをプロジェクトツリーのルートにある単一の.gitフォルダーに格納します。だから私は2つのことの1つをすることができました。

1. 製品ごとに個別のプロジェクトを設定します。
2. 単一の大規模なプロジェクトを設定し、製品をサブフォルダーに保存します。

製品間に依存関係があるため、単一の大規模なプロジェクトが適切であると思われます。すべての開発者がコードを共有できるサーバーを使用します。これはSSHとHTTPですでに機能しており、その部分が大好きです。ただし、SVNのリポジトリのサイズはすでに数GBであるため、各マシンのリポジトリ全体をドラッグすることは、特に過剰なネットワーク帯域幅に対して課金されるため、悪い考えのように思えます。

Linuxカーネルプロジェクトリポジトリも同様に大きいと思います。そのため、Gitでこれを処理する適切な方法が必要ですが、まだわかりません。

非常に大規模なマルチプロジェクトリポジトリを操作するためのガイドラインまたはベストプラクティスはありますか？

ガイドラインは、Gitの制限に関しては単純です。

• プロジェクトごとに1つのリポジトリ
• サブモジュールを含むメインプロジェクト。

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

OPポール・アレクサンダーの コメント：

これは、subversionが提供する「外部」サポートに似ています。
私たちはこれを試してみましたが、プロジェクトは相互に依存しながら同時に開発されているため、外部のバージョン参照を常に更新するのは非常に面倒です。別のオプションはありますか？

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

• メインプロジェクト内からサブプロジェクトを直接開発します（「サブモジュールの真の性質」で説明）。
• または、サブレポで、origin別の場所で開発されている同じサブレポを参照します。そこから、そのサブレポから他の場所で行われた変更をプルする必要があります。

どちらの場合も、新しい構成を記録するために、メインプロジェクトをコミットすることを忘れないでください。ここで更新する「外部」プロパティはありません。すべてのプロセスははるかに自然です。

正直なところ、これは本当の苦痛のように聞こえ、開発者が毎回手動で何かを行う必要があるものは、メンテナンスのバグの定期的な原因になるだけです。
スーパープロジェクトのいくつかのスクリプトを使用して、これを自動化することを検討します。

私は答えた：

正直なところ、あなたは正しかったかもしれません...それは最新のGitリリース1.7.1までです。
git diffそして、git statusの両方がメインプロジェクトから実行した場合でも、アカウントのサブモジュールの状態に取ることを学びました。
サブモジュールの変更を見逃すことはありません。

言われていること：

• サブモジュールはSVNエクスターナルとは異なります。「gitサブモジュールがsvnエクスターナルと互換性がないのはなぜですか？」を参照してください。
• サブモジュールの管理には注意が必要です。「gitサブモジュールはどのように機能するのですか？」を参照してください。

GitSlaveを使用すると、複数の独立したリポジトリを1つとして管理できます。各リポジトリは通常のgitコマンドで操作できますが、gitslaveを使用すると、すべてのリポジトリでコマンドをさらに実行できます。

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

プロジェクトごとのリポジトリには、コンポーネント化とMavenのようなツールを使用した簡素化されたビルドの利点があります。プロジェクトごとのリポジトリは、誤ったコミットのコミットに関して、開発者が変更しているものの範囲を制限することによって保護を追加します。