プロジェクトの複数のリリースバージョンのGitflow戦略

Question

私は私のプロジェクト（私たちはTFSを使用しています）の分岐方法&のマージ戦略を設計しています。プロジェクトには、複数のリリースバージョンがある予定です。

• テスターからの切迫した緑色の光の後、バージョンv1.0のは1つのクライアントにリリースされます：現在の計画があるv2.0の

  でv1.0alphaをテストして取り組んでいます。 （すでにdevに）

• バージョンv1.1のは、クライアントの数十にインストールされる 5-6クライアント
• バージョン1.2以降に展開されます。
• など

私たちは、最新のバージョンに古いクライアントのアップグレードを強制しようとしますが、原因プロジェクトの性質と市場にそれが数ヶ月することができます（年？）クライアントがアップグレードするため。

標準のgitflowを使用したいのですが、単一のバージョンを使用する方が適切です。私はgitflowの簡素化を設計した：

アプローチは次のとおりです。クライアントはバグが直って欲しい

• 場合は、我々は彼のバージョンのリリースブランチにそれを修正すると、彼はにアップグレードする必要があります彼のバージョンの最新の改訂版。たとえば、バグのあるv1.0のクライアントは、v1.0.5にアップグレードする必要があります。バグが他のバージョンで発生した場合は、そこで修正します。
• クライアントが新機能を望んでいる場合は、最新バージョンで開発し、必要に応じてアップグレードを実行します。たとえば、新しいバージョンを必要とするv1.0.5のクライアントは、v1.2にアップグレードする必要があります。
• 特定のバージョンのすべてのクライアントをアップグレードすると、そのリリースブランチが削除されます。たとえば、v1.0のクライアントがアップグレードすると、v1.0のリリースブランチが破棄されます。

だから、重要度の順で、私の質問は以下のとおりです。

ウィル

1. 私のアプローチの仕事？あなたが見ることができるすべての問題？
2. git-flowにはこの "複数バージョンシナリオ"のパターンはありますか？
3. Gitflowにはマスターブランチがあります。マスターブランチを持っていないのは大丈夫ですか？異なるリリースのブランチを「マスター」と見なすことができますか？
4. DevとReleaseブランチの名前はどのようにしますか？

Answer 1

1. あなたのアプローチはうまくいくはずです。 GitFlowには魔法のようなものは何もなく、あなたのニーズに応えるバリエーションは大丈夫です。 Git自体は別のワークフローでは問題ありません。良い例はGithubの流れです、http://scottchacon.com/2011/08/31/github-flow.htmlを見てください。

あなたが考える可能性がいくつかのこと：

A）「の原理以上の驚きは、」：することができますよう、標準に近い保つようにしてください。つまり、あなたはi）すべてを書き上げるのではなく、ウェブ上で入手可能なドキュメンテーションを指し示すことを意味します。ii）新しい開発者があなたのプロジェクトに参加したり、ちょうど仕事をするのを簡単にします。 このように、マスターブランチは必要であるからではなく、それがないときに混乱させる可能性があり、何年も前から説明する必要があります。 gitのブランチは「ちょうど」名前です（もう少しですが、私の意味が分かります）。同じ名前を付ける唯一の理由は、コンベンションです。

b）プロジェクトに携わっている開発者は何人ですか？存在する場合は、Devブランチを統合ブランチと見なして、安定したブランチとしてマスターブランチを使用します。あなたが不安定になることを可能にするdevブランチを持つことは、多くの開発者の多くの問題を解決するかもしれません。機能から1つ、修正から1つの2つのチームがコミットすると、ビルドは赤くなり、チームは互いに批判し、第3チームは新しいリリースブランチを手に入れようとするができない。あなたがプルリクエストで保護することもできる、安定した、常にグリーンのビルドマスターブランチを持つことは、非常にうれしく、よりリラックスした環境になります。

2）基本的なGitflowはリリースを中心にしているため、あまりよくありません。あなたは同時に複数のリリースを持っています。あなたはほぼそこにいますが、[Jakob Ehn's]（https://github.com/jakobehn）Gitflow extention to Visual Studioのような標準的なツールは、あなたが新しいものを開くことを許可される前にリリースを閉じるようにします。それをリラックスさせるようヤコブに依頼すれば、ツールがあなたのために働くでしょう。それ以外の場合は、規約に従ってください。手動で行うこともできます。

3）マスターについての上記のポイント1を参照し、それを持っていないとよい理由がないのはなぜですか？もちろん、リリースブランチはマスターの一種だと考えることができますが、あなたの記述では実際にそのように振る舞いません。もしそうなら、どちらが本物のマスターですか？あなたが作成したものが、最新のものと思われるものですか？安定したマスターを持つことで、多くの質問が解決されます。

4）DevまたはDevelopの場合、機能にはDev/NewHelpPageやFeature/NewHelpPage（できるだけ近いもの）の名前を持つ必要があります（gitflow規約に近い）。ブランチをリリースすると、セマンティックバージョン管理（http://semver.org）の原則に従っているようですので、それを使用しないでください：Release/V1.0、Release/V1.1など。 hotfixブランチはRelease/V1.0.1です。
開発者がそれが何であるかを簡単に理解できるように、好ましくは誰かに尋ねる必要がないように名前を付けます。

できるだけ多くの慣習に従ってください。それはうまくいく傾向があります。 Git自体はほとんどすべての分岐スキームで動作します。

[編集] ちょうどJakobと簡単にチャットしました。彼はサポートブランチをサポートするという要望を持っていたと言いました。また、別のgitflowシナリオではthis excellent postを指していました。下部には、サポートブランチのフローがあります。