6

現在、バージョン管理を（CVSNTから）Gitに切り替えようとしています。驚いたことに、私が問題を抱えていたのは、ステージングエリアの分散性や概念ではありませんでした。しかし、分岐、マージ、タグ付けなどのAFAICT操作は、ファイルやディレクトリレベルではなく、常にリポジトリレベルで適用されるという事実に頭を悩ませています...

さまざまなプロジェクトで多くのコードを再利用しています。私の作業エリアは現在次のようになっています。

/Dev
  /Libs
    /LibA
    /LibB
    /LibC
  /Project1
  /Project2
  /Project3
  /WebDev

ここで、Project1がLibAとLibBに依存し、Project2がLibBとLibCに依存し、Project3にlibの依存関係がないとします。これらのライブラリの一部は後でDLL（またはBPL-私たちの主要な開発環境はDelphi）にコンパイルされ、その他はファイルごとにメインプロジェクトに含まれる再利用可能なコードの単なるコレクションです。

WebDevには、Project1、2、3に関する情報も含まれているため、それらと一緒にタグ付けする必要がある場合がある、当社の（ほとんど静的な）会社のWebサイトのコードが含まれています。

プロジェクトを頻繁に切り替えるので、通常はこれらすべてを同時にチェックアウトし、必要に応じてlibディレクトリを適切なプロジェクトブランチにオンザフライで更新します。

これをGitでどのようにモデル化するのでしょうか。また、この作業方法に固執するのも理にかなっていますか？私はgitサブモジュールについて読んだことがありますが、これまでのところ、いくつかの理由で、ここでそれをどのように適用するかがわかりません。

  • 私が理解している限り、サブモジュールは常にそれぞれの「スーパープロジェクト」内でチェックアウトされます。ただし、Delphiを使用して（設計時の）ライブラリコードの複数のコピーを管理することは、ロイヤルPITAであることがわかりました。これが、すべてのライブラリを個々のプロジェクトツリーの外部の共通ディレクトリに保持する理由の1つです。追加のコピーはビルド自動化によってのみチェックアウトされ、実際の作業を行うためにチェックアウトされることはありません。

  • ライブラリをプロジェクトから「独立」させたくありません。プロジェクトの1つにタグを付けたり分岐したりする場合は、常にそれぞれのライブラリにもタグを付けたり分岐したりします。メインプロジェクトの特定のタグ付きリビジョンに戻りたい場合は、ライブラリもその状態に戻したいと思います。可能であれば、タグ付け/分岐/チェックアウトは、プロジェクトとその依存関係に対して常に1つのステップで実行する必要があります。

私はすでにすべてを単一のGitリポジトリに入れようとしましたが、ライブラリコードは主にマスターブランチで管理され、「プロジェクト」はそれぞれ独自のブランチで管理されていますが、マスターブランチとプロジェクトブランチの間でライブラリの変更をマージしようとすると、プルされます無関係なライブラリからのすべてのファイルでも、これは私がまったく望んでいないことです...

これらすべてを解決するための最善の方法について何かアイデアはありますか？作業ツリーの新しいレイアウトを含め、ほとんどすべての提案を受け入れています。

誰かが私にサブモジュール（またはこれを達成するために必要な他のテクニック）についての実際の実践的なチュートリアルを教えてくれるなら、それも素晴らしいでしょう。

4

1 に答える 1

3
  • 最初：コンポーネントごとに1つのGitリポジトリ（コンポーネントはLibまたはプロジェクトです。Gitの制限を参照してください）
  • 2番目：1つの親プロジェクト（Dev）。その下ですべてのサブモジュールを宣言します。

そうすれば、devをすばやくチェックアウトしてから、作業するサブモジュールのみを初期化/更新できます（必要に応じてすべてを含む）。
タグ付けするとき、親リポジトリ「Dev」に適用されるタグは、すべてのサブモジュールの正確なコミットを参照します。つまり、古いバージョンに戻すと、前の状態とまったく同じサブモジュールが返されます。

その組織は「システムアプローチ」であり、コンポーネントの任意の部分を更新できます。

于 2011-01-26T13:08:28.263 に答える