5

私の会社では、バージョン管理ツールをRationalClearCaseからGitに変更中です。次の開発シナリオがあります。ClearCaseと同じ動作を実現するためにGitを使用する適切なパターンがあるかどうかを知りたいと思います。

これが私たちの状況に関するいくつかの基本的なポイントです：

  1. 個別のアプリケーションがいくつかあります。これらをAppA、AppB、およびAppCと呼びましょう。
  2. また、すべてのプロジェクトに共通する特定のファイル（ビルドスクリプトなど）もあります。これをツールと呼びましょう。
  3. AppA、AppB、またはAppCコードの特定のカットには、ツールコードの特定のカットが必要です。
  4. ほとんどの開発者は、ツールコードを変更することはありません。

ClearCaseの場合、次のようにモデル化しました。

コンポーネント：app_a、app_b、app_c、ツール

プロジェクト：AppA、AppB、AppC、ツール

Project AppAには、読み取り/書き込みコンポーネントとしてapp_aが含まれ、読み取り専用コンポーネントとしてツールが含まれています。

Project AppBには、読み取り/書き込みコンポーネントとしてapp_bが含まれ、読み取り専用コンポーネントとしてツールが含まれています。

Project AppCには、読み取り/書き込みコンポーネントとしてapp_cが含まれ、読み取り専用コンポーネントとしてツールが含まれています。

プロジェクトツールには、読み取り/書き込みコンポーネントとしてツールが含まれています。

App *プロジェクトの各ベースラインは、app_*とツールコンポーネントの両方のベースラインを参照します。開発者が推奨ベースラインにリベースすると、両方のコンポーネントから変更が取り込まれます。

Gitの場合、サブモジュールが正しい答えに最も近いものである可能性があると考えています。ただし、リポジトリをプル/リベースする場合、サブモジュールコードを更新するために追加の手順が必要になるようです。理想的には、透明性を保ちたいと思います。また、親リポジトリの観点から、サブモジュールで何が変更されたかを知る必要はありません。サブモジュール全体の特定の時点のみを考慮します。

4

1 に答える 1

4

まず、ClearCaseとgitの（UCMのような）構成の違いを必ず理解してください（「柔軟な分岐と静的な分岐（GITとClearcase / Accurev）」を参照）。ClearCaseとGitの違い
を見るとき、各UCMコンポーネントはGitでリポジトリとして表される必要があります。

「サブモジュールの本質」で説明されているように、サブモジュールを変更する場合は、追加の手順が必要です。
ただし、特定のSHA1を記録します。これは、各''をプルするときに必要なものですAPP。
gitslaveToolsを使用すると、''とのリンクをより緊密に保つことができますがAppx、シナリオに適合しないと思います。

サブモジュールを使用すると、次のことに注意してください。

  • ' Tools'のサブディレクトリを作成します' APPx'
  • 変更可能にします。
    gitには「読み取り専用」コンポーネントはありません。リポジトリにアクセスできる場合は、プッシュ/プルできます。
    本当に読み取りアクセスを強制する必要がある場合は、gitoliteと呼ばれる追加の「承認レイヤー」を追加する必要があります。
于 2012-06-22T21:44:09.700 に答える