複数のマスターブランチを持つGitflow
これはスレッド 複数の並列リリースブランチを持つGitフローとマスター および 複数のマスターブランチでgitを操作するための最良の方法は何ですか？ に似ていますが、そうではありませんまったく同じです...これはかなり似ていることがわかりました： 同じGITマスターを持つ複数のプロジェクト 、しかし私は私の特定のユースケースについて議論したいと思います...
私が働いている会社は、Gitワークフローのポリシーと手順を確立している最中です。記事で説明されている「Gitflow」モデルを使用したい http://nvie.com/posts/a-successful-git-branching-model/ または https：// www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow そして、この問題に関する多くの議論で一般的に参照されています。
ただし、文書化された解決策が見つからないという要件を持つユースケースがあります。プロジェクトを使用して複数の最終製品を作成した場合はどうなりますか？したがって、マスターブランチは、「リリースポイント」を単一の製品であるかのように表すことはできません。おそらくマスターから別のブランチが必要なようですか？では、複数の並列リリースブランチですか？
たとえば、プロジェクトがさまざまなスキン、フレーバー、またはバリエーションを持つことができるもののバックボーンまたはエンジンとして機能するが、結果として得られる完全な最終製品のそれぞれを1つのリポジトリに保存したい場合はどうでしょうか。
私の特定のシナリオでは、Linuxサーバーで実行されるプログラムがありますが、ローカルのWindowsアプリケーションとしても配布されています。これらの異なるバージョンには、プロジェクトの大きなチャンクがあり、いずれかのリリースに含まれる場合と含まれない場合があります。例として、リポジトリがサーバー専用の場合は含める必要がないが、他の方法では存在しないローカル配布用に含める必要があるライブラリがサーバー上にあります。特定のリリースポイントでリポジトリの更新をサーバーにプルしたいのですが、そこに属していない部分は省略します。
マスターブランチから、「サーバーリリース」ブランチと「ローカルリリース」ブランチを作成しますか？
次に、開発ブランチ（およびその機能）はどこから離れますか？コード開発は実際には両方に99％適用できるため、それぞれが独自のリリースから提供される複数の開発ブランチは必要ありません。 1つの開発ブランチを1つにマージしてから、もう1つのリリースにマージする必要がありますか？
コードの99％が2つの製品間で共有されている場合、同じリポジトリを簡単に共有できます。 2つの製品が同じリリースサイクルにある限り、単一のリリース/開発/マスターブランチを持つことができます。たとえば、バージョン2.0が同時に出荷されます。
マスターブランチから、「サーバーリリース」ブランチと「ローカルリリース」ブランチを作成しますか？
Gitflowでは、実際に開発からリリースを分岐します。ただし、リリースサイクルが異なる場合は、製品ごとにリリースブランチを作成することを妨げるものは何もありません。その後、リリースブランチを開発ブランチとマスターブランチにマージして、自分の時間に自由に実行できます。ここでの唯一のことは、各製品がリリースサイクルのどこにあるかを確認できるように、マスターブランチに2つの異なるフレーバーのタグが必要になる可能性があるということです。または、タグを同じ形式に保つために、2つのマスターブランチ（製品ごとに1つ）があり、それぞれの製品の機能が完了したときにそれぞれにマージされます。