[解決済み] Git-flowとmasterによる複数並行リリースブランチの実現

質問

私たちは Git の成功したブランチ・モデル を採用しようとしています。現在、私たちは少なくとも二つのリリースブランチに取り組んでいます。一つは最新の安定版リリース用、もう一つは次の ("preview") リリース用です。私が理解していないのは、なぜすべてのリリースが "linearized" で マスター にリニアライズされ、そこにタグ付けされていることです。なぜリリースブランチにタグを付けないのでしょうか？なぜ マスター をまったく使わないのですか? あるいは、なぜ を開発するのか？ ブランチを使用せず マスター を使用しないのですか？

どのように解決するのですか？

git-flow モデルでは、あなたの "latest released" のバージョンは、実際には master にマップされ、一方あなたの "プレビューリリース" は、git-flow の release ブランチにマッピングされます。からフォークされています。 develop にマージされ、最終的に master にマージされます。そしてこれがあなたの最新リリースとなり、あなたは通常、git-flow を使ってそのリリースのバグのみを修正することになります。 hotfix ブランチを使用します。このように、あなたの master は常に最新のリリースバージョンの最も安定した状態を表します。

古いリリースのバグを修正したり、その他の開発をそこで行ないたい場合は support の適切なコミットから master (にある適切なコミットからブランチします（このとき すべて のバージョンがそこに作成されます)。 support ブランチはまだ実験的なものです ( ドキュメントによると ) で、文書化も十分ではありません。しかし、コマンドラインヘルプを見ればわかるように

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

にマージされることを意図していません。 master また develop . 古いリリースの修正や、顧客からリクエストされた機能を古いリリースで実装することはできないし、すべきでないので、これは通常、問題ありません。 master . それでもなお、修正をメインの開発ラインに移植したいと考えるのであれば ( master と develop を含む) を開始するだけです。 hotfix を開始し、変更箇所をチェリーピックし、最後に hotfix .