注： 私の質問は、特定の問題（Liferayを含む）に焦点を当てていますが、gitで同じプロジェクトのさまざまなバージョンを維持する必要がある人にとって役立つことを願っています。

私はLiferay Portalの多くのプラグインを書いている会社で働いています。これらのプラグイン（ポートレット、テーマなど）は通常再利用可能であり、もちろん、ポータルの新しいバージョンに合わせて更新する必要があります。

しかし、移行する必要があり、私たちは、言うのLiferayの新バージョンへのポートレットせることが通常であるとその前のバージョンを維持します。また、一部のクライアントに対して非常に具体的なカスタマイズを作成する必要が頻繁にありますが、これは「メインバージョン」に追加しても意味がありません。

これらの要件により作業が複雑になりますが、幸いなことに、いくつかの単純化を想定できます。たとえば、プラグインは一度に1人のプログラマのみが頻繁に更新します。プラグインに複数の機能を同時に追加することは非常にまれです。

現在、Gitoriousに移行しています。このようなシナリオの分岐モデルを考えています。

私のモデル

私が提案したのは：

1. 各プラグインには、プロジェクト内のGitoriousに独自のリポジトリがあります。たとえば、子猫を表示するためのポートレットにはkittens-portlet、liferay-portletsプロジェクト内にリポジトリがあります。
2. 新しいプラグインを作成するときは、Liferayバージョンに応じて名前が付けられたブランチ（たとえば、lf5.2）に作成します。
3. プラグインで更新が行われるたびに、更新は本番環境で承認およびデプロイされ、プラグインにバージョン（たとえばlf5.2v1、lf5.2v2など）のタグが付けられます*
4. プラグインをLiferayの新しいバージョンに移植するたびに、最新バージョンをブランチします（たとえば、ブランチを作成しlf6.0ます）。
5. 本番環境に入ると、新しいブランチのヘッドはなどのタグを受け取りlf6.0v1ます。
6. クライアント固有の方法でプラグインをカスタマイズする必要があるたびに、クライアントの名前でブランチを作成します（たとえば、lf5.2clientcorpクライアント「ClientCorp Inc.」のブランチを作成します）

これは通常とは異なるモデルですmaster。マージされないブランチはまったくなく、多くあります。これは、そのようなモデルを持つリポジトリが次のように見えると思う方法です：

友人がこのシステムをかなり複雑でエラーが発生しやすいと感じました。彼は、優れた人気のあるVincent Driessenモデルを提案しました。もちろん素晴らしい（そしてテスト済み！）が、私たちの状況には複雑すぎるようだ。

私の友人のモデル

次に、彼は別のモデルを提案しました。Liferayバージョンの各プラグインのリポジトリを作成し（したがって、を作成しkittens-lf5.2-portlet、次にを作成しますkittens-lf6.0-portlet）、それぞれにmasterブランチとdevelopブランチがあります。これmasterにより、いつでも展開の準備が整います。（それとも、他の方法で回避することが、可能性masterとstableによって示唆されているように、スティーブLosh）。

これは非常に簡単ですが、私はこのシステムが好きではありませんでした：

1. その結果、プロジェクトに膨大な数のリポジトリが作成され、Gitoriousの閲覧が困難になる可能性があります。
2. プロジェクトのディレクトリの名前が関連しています。誰かがリポジトリをkittens-lf6.0-portletディレクトリにクローンし、antを使用してWARを生成する場合（通常どおり）、WAR名kittens-lf6.0-portletも同様になります。このポートレットの古いバージョン（kittens-portletたとえば、名前が付けられている）は、アップグレードされたポータルでは異なる（おそらく欠落している）ポートレットと見なされます。少し注意すれば回避できますが、回避したいです。
3. 同じプラグインの異なるバージョンは別々に維持されます。私は私の心を壊します:(
4. kittens-lf6.0-portlet リポジトリのい名前だと思います。

私は、2つの最後のポイント-これも2つのより主観的なポイント-が私の不本意の主な理由だと思います。それにもかかわらず、すべての4つの異議が立っています。

OTOH、私自身の提案は私には奇妙に思われ、それに隠されたバグがあるのだろうかと思います。OT3rdH gitは非常に強力で柔軟性があるため、その可能性を探ることに恥ずかしさは感じないと思います。

だから、私は尋ねます：

1. 最高のモデルは何でしょうか？わたしの提案？友達のモデル？今では伝統的なビンセント・ドリーセンのシステムですか？
2. 他にどのような分岐モデルを提案しますか？
3. 私のモデルが悪いと思うなら、なぜそう思うのですか？私は欠点と盲点が何であるかを学びたいです。

*実際には、次のようなバージョンでコミットにタグ付けすることを好みますv1が、どうやらgitのタグはブランチ内でスコープされていません-つまり、1 つのv1タグlf5.2ともう1つのタグを持つことはできませんでしたlf6.0ので、ブランチ。それは正しいですか？

私がこれを適切に読んだ場合、ブランチは基本的に開発のメインラインからのワンショットの逸脱であり、メインラインにマージされることは決してなく、メインラインの進歩はこれらのブランチに適用されません。唯一の違いは、ブランチに適用する必要性に基づいてブランチのバージョンに適したバグ修正を行うことです。

答えは、日々のワークフローに左右されます。1つのブランチで作業する開発者の数や変更の数は、赤いニシンです。私はあなたの主なニーズは、どのブランチがメインブランチの変更からバグ修正アップデートを取得したいのかを見ていることです。相互受粉の必要性がまったくなかった場合、別のリポジトリがそれを強制しますが、そのシナリオは私が理解しているプロジェクトの現実と一致しません。

プロジェクトでブランチを開発のメインラインに戻す必要がある場合、Driessenモデルはうまく機能しますが、それは必要ありません。それでも、ライブの製品に取り組んでいる場合、InDevelopment and StableReleaseコンセプトを維持するメリットがあると思います。

要約すると、プロジェクトは分岐モデルに加えて、メインラインにDriessenを少し加えてもうまく機能すると思います。あなたのマイレージは異なる場合があります; 私は常に、「ライブ」ブランチに変わる「保留中のリリース」ブランチと、さまざまな時点で修正と変更の相互受粉を必要とする別個の「次のリリース」で作業してきたため、私の認識は偏っています。

何が私を困らせるのは、各ポートレットが独自のリポジトリを持っているという事実です（ただし、ストーリーは完全ではないかもしれません）。個人的には、プロジェクトごとにリポジトリを作成します。多くの場合、プロジェクトには複数のポートレットがあり、すべて同じバージョンのLiferayに対して同じ実行でビルドされます。各プロジェクトは、Liferayの異なるバージョンに対してビルドする既存のプロジェクトの複製にすることができますが、違いが大きすぎる場合にのみ製品を分割します。Liferay 5.1および5.2に対してビルドが機能する場合、プロジェクトを分割しません。スクリプトまたはMaven（または両方）を使用して、すべてが機能するようにします。Wiki（またはTrello）を使用して各製品を管理し、Liferayのどのバージョンでビルドできるかを考えます。

ところで、私はJavaプログラマーであり、Mavenスペシャリスト、ビルドスペシャリストであり、Liferayおよびその他のポータルサーバー（IBM WebSphereおよびGlassfish）の経験があります。

しかし、これはちょうど私の0.02ユーロです。