1

Gitリポジトリのベストプラクティスに似た構造で、従来のn層設計の複数のプロジェクトがあり、次のリポジトリがあります。

  Shared
  ProjA
  ProjB

を使用し、場合ProjAによってProjBはに貢献する、2〜3人の別々のチームによって開発されSharedます。

サブツリーやサブモジュールについて読んだ恐怖が非常に多いため、サブツリーやサブモジュールを必要としない単純なモデルを考えました。そのようなことがうまくいくかどうかを確認してお知らせください。

  • gitflowモデルに従って、それぞれProjおよびそれぞれが別々のリポジトリに存在しますShared
  • Jenkinsは、develop3つのリポジトリすべてのブランチから最新のものを使用してビルドします
  • release.shのはとの両方Projにマージされ、両方にタグを作成し、Jenkinsはからビルドしてデプロイします。masterProjSharedmaster

これは機能しますか？私たちはたった8人で、gitに移行しているだけなので、できるだけシンプルにしたいと思います。サブモジュールとサブツリーの学習曲線を回避できれば、もっと幸せになるでしょう。それとも私たちでしょうか？

4

2 に答える 2

1

あなたの問題はgit構造化ではないと思いますが、プロジェクトの依存関係、たとえばSVNはあなたの人生を楽にしません。

2 つのプロジェクトが共有プロジェクトに依存している場合、それを指定することを避けるべきではないと思います。

チーム B の誰かがプロジェクト A のリリース直前に変更を共有した場合はどうなりますか? プロジェクト A に不要な変更が加えられる可能性があります。

プロジェクトのバージョン管理を使用する必要があることを克服するには、ここで git サブモジュールが助けになります。サブモジュールは、プロジェクト X とsharedの特定の時点との間の依存関係です。

git サブモジュールに代わるものは、アーティファクトのバージョン対応の依存関係です。ほとんどの (すべて?) 最新の言語でそれを行うことができます。たとえば Java では、maven/ivy/gradle を使用してプロジェクトの依存関係を定義します。(いくつかのアーティファクト リポジトリに共有をアップロードする必要があります)

代替手段が git サブモジュールよりも単純であるとは言いませんが、プロジェクトの構造がより複雑になり、多くのアーティファクトが相互に依存している場合は、これが (必須の?) 方法です。

于 2013-03-01T18:58:06.123 に答える
1

の正確な参照を(バージョン管理されたテキスト ファイルまたは として) どこかに保持ProjAしていれば、それは機能します。ProjBgit notesShared

ビルド スケジューラの背後にある考え方は再現性です。このようなツールは、特定のビルドに使用される正確な構成 (つまり、SHA1 参照のリスト) を再現できる必要があります。
これにより、後でビルドに再度アクセスできます。

于 2013-02-26T10:04:35.730 に答える