32

一元化されたSCMシステムからGITに切り替えています。OK、どちらかを認めます。それはVisualSourceSafeです。したがって、Gitコマンドとワークフローの学習曲線を乗り越えることに加えて、私が現在直面している最大の問題は、単一または複数のリポジトリのいくつかのフレーバーに関して、現在のリポジトリをGitに移行する方法です。

私はこの質問がさまざまな方法で尋ねられるのを見てきましたが、通常は基本的なものです...「私はいくつかの低レベルのライブラリを共有したいアプリケーションを持っています」そして定型の応答は常に「別々のリポジトリを使用する」および/または「使用するこのパターンをいつ/なぜ使用する必要があるのか​​（何を克服するのか、何を排除するのか）についての説明があまりない「Gitサブモジュール」特にGitを初めて使用する人にとっては。

ただし、誰かが露骨に尋ねるのはまだ見たことがありません。「各レイヤーが独自のプロジェクトである従来のn層開発（UI、ビジネス、データ、共有ツール）がある場合、1つまたは複数のレイヤーを使用する必要があります。リポジトリ？」ほとんどの場合、新しい「機能」が追加されると、コードの変更が各レイヤーに波及するため、私にはわかりません。

Gitに関する問題を複雑にするために、これらのレイヤーを「フレームワーク」全体に複製して、開発者の観点からより管理しやすいプロジェクト/コンポーネントを作成しました。この議論の目的のために、これらのプロジェクト/レイヤーのコレクションを「タヒチ」と呼びましょう。これは「製品」全体を表します。

私たちのセットアップの最後の「レイヤー」は、タヒチをカスタマイズ/拡張するクライアントWebサイト/プロジェクトの追加です。これをフォルダ構造で表すと、次のようになります。

/Clients
  /Client1
  /Client2

/UI Layer
  /CoreWebsite (views/models/etc)
  /WebsiteHelper (contains 'web' helpers appropriate for any website)
  /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites)

/BusinessLayer (logic projects for different 'frameworks')
  /Framework1.Business
  /Framework2.Business

/DataLayer
  /Framework1.Data
  /Framework2.Data

/Core (projects that are shared tools useable by any project/layer)
  /SharedLib1
  /SharedLib2

複数のプロジェクトで従来のn層設計をどのように拡張したかを説明した後、同様の状況でどのような決定を下したかについての経験を探しています（単純なUI、ビジネス、データ分離でさえ、あなただけでした）使用）そしてあなたの決定のために何がより簡単/より困難でしたか。サブモジュールがどのように少し苦痛になる可能性があるかについての予備的な読書で私は正しいですか？利益の価値よりも多くの痛みがありますか？

私の直感的な反応は、タヒチの1つのリポジトリ（「クライアントプロジェクト」を除くすべてのプロジェクト）、次に各クライアントの1つのリポジトリに対するものです。私が推測しているタヒチのソース全体は、1万未満のファイルでなければなりません。これが私の推論です（そして私は批判を歓迎します）

  • Gitでは、「機能」と個々の「プロジェクト/ファイル」の履歴を追跡したいと考えています。プロジェクトを分離しても、「機能」は常に複数のプロジェクトにまたがっています。
  • コアサイトでコーディングされた「機能」は、ほとんどの場合、コアWebサイトと「フレームワーク」のすべてのプロジェクト（つまり、CoreWebsite、Framework1.Business、Framework1.Data）に最小限の影響を与えます。
  • 機能は複数のフレームワークに簡単にまたがることができます（実装する機能の10％はフレームワークにまたがると思います-CoreWebsite、Framework1.Business、Framework1.Data、Framework2.Business、Framework2.Data）
  • 同様に、機能では1つ以上のSharedLibプロジェクトや「UIWebサイトヘルパー」プロジェクトへの変更が必要になる場合があります。
  • クライアントのカスタムコードへの変更は、ほとんどの場合、リポジトリに対してローカルであるだけであり、「機能変更セット全体」が何であるかを確認するために他のコンポーネントへの変更を追跡する必要はありません。
  • 機能がプロジェクトにまたがってスコープ全体を表示することを考えると、各プロジェクトが独自のリポジトリである場合、リポジトリ全体の*すべての*コード変更を分析しようとするのは面倒だと思われますか？

前もって感謝します。

4

1 に答える 1

14

ほとんどの人が別々のリポジトリを作成するようにアドバイスする理由は、変更と変更セットを分離するためです。誰かがクライアント プロジェクトに変更を加えた場合 (他の人には実際には影響しないとあなたは言います)、誰かがコード ベース全体を更新する理由はありません。関心のあるプロジェクトから変更を取得するだけです。

Git サブモジュールは、Subversion のエクスターナルのようなものです。それぞれが別のレイヤーになるように git リポジトリを設定し、サブモジュールを使用して、さまざまな階層に必要なプロジェクトを含めることができます。

たとえば、次のようにします。

/Core -- It's own git repository that contains it's base files (as you had outlined)
  /SharedLib1
  /SharedLib2

/UI Layer -- Own git repository 
  /CoreWebsite
  /WebsiteHelper
  /Tahiti.WebsiteHelpers
  /Core -- Git Submodule to the /Core repository
    /SharedLib1
    /SharedLib2

これにより、/Core リポジトリへのすべての更新が UI レイヤー リポジトリに確実に取り込まれます。また、共有ライブラリを更新する必要がある場合、5 ～ 6 個のプロジェクトにわたって更新する必要がないことも意味します。

于 2011-04-07T14:36:54.770 に答える