GITリポジトリ上のモジュラーJavaアプリケーション

Question

私は「モジュール式Javaアプリケーション」を開発していますが、それは約60個の独立したモジュールを持っています。

私はGITの下でこのタイプのアプリケーションを構築するための最良の方法が何かを理解しようとしています。

私は自分自身をよりよく説明します：

私はSVNで数年間働いてきたと私は、このようなSVNなどの集中バージョン管理ツールの下で、このようなプロジェクトを構築するために、それは本当に簡単になり、しばらくI GITのベストプラクティスや長所/短所については分かりません。 SVNで

：

mod_A 
    |___trunk 
    |___branches 
    | |___branch_A 
    | 
    |___tags 
mod_B 
    |___trunk 
    |___branches 
    | |___branch_A 
    | |___branch_B 
    | 
    |___tags  

OR

を：は

私は例えば、私は同様の結果と、2つの異なるアプローチを検討する

同じリポジトリの下にあるすべてのプロジェクトをインポートします

trunk 
    |___mod_a 
    |___mod_b 
    |___mod_c 
branches 
    |___branch_A 
    | |___mod_a 
    |___branch_B 
     |___mod_a 
     |___mod_b 

どちらの方法でも、特定の機能のために分岐されたモジュールのような情報を得ることは本当に簡単ですし、将来のモジュールからアプリケーションを見るだけでなく、将来の支店からも見ることができます。

また、両方の構造を使用すると、いつでもそれらのモジュールをすべて分岐することなくモジュールの一部だけを簡単に分岐することができます。また、現時点では

私が働いているモジュラーアプリケーションは、この構造は、いくつかの利点をもたらす場合でも、私の見解では、任意のモジュールのための単一の独立したレポで構成されて、います

GITで

本当の大きな問題。

実際、アプリケーションの全体像を明確に把握することは難しいようです。なぜなら、すべてのリポジトリに接続してブランチをチェックして、特定のブランチにどのモジュールが関係しているのかを知る必要があります。私のアプリケーションの分岐バージョンを管理することができます。たとえば、アプリケーション全体ではなく、特定のBUG_FIXINGまたはFEATUREブランチで分岐するモジュールが7つだけであれば、GITからこの情報を取得する方法はありません。情報をカスタム方法で

アプリケーションが同じリポジトリ内に設定されていても、モジュールのサブセットだけを分岐させることはできませんでした。「Gitは個々のディレクトリではなくリポジトリ全体で動作します。

GITサブモジュールをソリューションとすることができますか？私が考慮していない他のアプローチはありますか？あるいは間違った前提から移動していますか？

ありがとうございます！

Answer 1

最初に、すべてのモジュールが同じプロジェクトで動作するので、1つのSVNリポジトリで管理しているgit repoでモジュールJavaアプリケーションを管理する必要があります。あなたのアプリケーションのための分岐モジュール構造のために

、私は別の枝（modX）内の各モジュールを管理提案します、そして、あなたのプロジェクト全体はmasterブランチで管理します。

作業の流れがあることができます：

• はmasterブランチのプロジェクトレベルのファイルを管理します。マスターブランチの構造：

  Root (master branch) 
      |___... (project level files) 
  

• アウトモジュール分岐マスタから（例えばmodA分岐、modB分岐及びmodCブランチとして）。プロジェクトレベルのファイルを削除し、モジュールのファイルをmod_Xフォルダに追加しました。このような枝MODA用として

  、構造は次のとおりです。

  Root (modA branch) 
      |___mod_A (folder) 
        |___... (module A level files) 
  

• あなたは、モジュールXのための作業を終えたとき、masterブランチにmodXブランチをマージします。

• すべてのモジュールは、仕事を終え（およびmasterにマージ）された後、masterブランチのファイル構造は次のようになります。

  Root (master branch) 
      |___... (project level files) 
      |___mod_A (folder) 
        |___... (module A level files) 
      |___mod_B (folder) 
        |___... (module B level files) 
      |___mod_C (folder) 
        |___... (module C level files) 
  

• あなたはmodXブランチのモジュールXを更新した場合は、再度modXブランチをマージmasterに分岐して、アプリケーションが更新されていることを確認します。 Javaアプリケーションのための製品版として

  1. master支店：

  2. はあなたにもdevelop、featureとhotfix枝に/テスト/ fixbugを開発することができ、プロジェクトレベル（アプリケーションアグリゲータ）ファイルを維持するために。
  3. developブランチ（masterブランチからチェックアウトする必要がある長いリビングブランチ）は、すべての開発者がそれに取り組むために使用されます。変更されたアプリケーションが正常にビルドされたら、developをmasterにマージすることができます。
  4. featureブランチは短い生きているブランチです。アプリケーションの新しい機能を開発する必要がある場合は、developブランチの機能ブランチをチェックアウトすることができます。そして、機能が完了し、機能ブランチをdevelopブランチにマージしてコードを確認します。
  5. hotfixブランチも短いブランチです。あなたは、バグが修正されたときに、ブランチ上のバグを修正することができ、developブランチにホットフィックスブランチをマージします。

  さらに、a successful branching modelがあり、プロジェクトレベル（アプリケーションアグリゲータ）ファイルの管理を参照できます。

Answer 2

脇：別のモジュールを管理するためにブランチを使用しないでください。ブランチは短命で、リリースの準備ができたら最終的にマスターに合流します。

---

モジュールが「変更/解放」すると、1つのリポジトリに保持することができます。各モジュールがSVNの独自のトランク/ブランチフォルダを持っていたという事実は、それらが別々に変わることを示しているようです。

Javaアプリケーションでmavenを使用している場合は、マルチモジュールプロジェクトとして1つのリポジトリにセットアップすることができます。

個別のリポジトリを使用する場合は、ブランチにも同様に名前を付けて（チケット番号などを追加してfeature/ticket-123-more-cow-bellsなど）、ある機能が複数のモジュール/リポジトリに影響を及ぼすことがわかります。

モジュールごとに別々のリポジトリを使用している場合は、gitサブモジュールを使用してそれらを結合することができますが、これは回避策です。

おそらくまたreading about a few different git branching strategiesは、ブランチについての 'git thinks'の理解に役立ちます。