web-dev-qa-db-ja.com

git-flowに従って、以前のリリースのホットフィックスをどのように処理する必要がありますか？

Git-flow分岐モデル ここに記載 および tools here を使用しようとする場合、この状況をどのように処理する必要がありますか？

1.0リリースと2.0リリースを作成しました。次に、1.0用の修正プログラムを作成する必要があります。 1.0タグからホットフィックスブランチを作成し、そこに修正を実装します。しかし、その後はどうなりますか？

通常、マスターにマージし、そこに1.1リリースタグを配置します。しかし、1.1をmasterの2.0の後のポイントにマージすることはできません。

ホットフィックスブランチにリリースタグを置くことができると思いますが、リリースタグを含むマスターの横に永続的なブランチが作成されます。それは正しい方法ですか？

gitbranchgit-flowhotfix
86
Klas Mellbourn

Gitフローには「サポート」ブランチの概念があるようです。これは、以前のリリースに修正プログラムを追加するために使用されます。

このスレッドには詳細情報があります 、これらの例：

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

...修正してから：

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

またはgit flowコマンドを使用して

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

...変更を行います：

git flow hotfix finish 6.0.1
65
Klas Mellbourn

興味深い質問です！リンクしたフローは、マスターが生産を追跡できることを前提としています。これは、製品バージョンが厳密に増加している場合にのみ機能します。これは通常、1つの製品バージョンのみを持つWebサイトに当てはまります。

複数の実動バージョンを維持する必要がある場合、実動を追跡する1つのブランチでは不十分です。解決策は、生産を追跡するためにマスターを使用しないことです。代わりに、release1、release2などのブランチを使用します。

このアプローチでは、ホットフィックスブランチさえ必要ない場合があります。 release1ブランチの問題を修正できます。修正が十分であれば、release1.1ブランチにrelease1タグを作成します。

30
Andomar

git-flowは、マスターが追跡しやすいように、一度に1つのリリースラインのみをサポートしていると想定しています。 1つ以上を維持している場合は、git-flowプロセスを変更して、サポートしている個別のリリース（master-1、master-2）の複数のトラッカーを持つようにする必要があります。最新のリリースラインの特定のトラッカー（master-2の代わりのマスター）に加えて、またはその代わりに、引き続きmasterを使用して最新のリリースラインを追跡できます。

残念ながら、使用しているgit-flowツールはおそらく変更する必要がありますが、gitコマンドでこの特定のケースを直接処理するためにgit-flowプロセスに精通していることを願っています。

7
Bert F

git config --add gitflow.multi-hotfix trueこのコマンドはうまくいくようです！

0
Laila