私の会社には、リリースのテストとビルドに使用する CI/Build サーバーがあります (機能と開発ブランチも同様です)。git フローの分岐モデルでは、リリース時に開発を分岐し、(たとえば) release-1.4 という名前を付けます。その後、CI/ビルド サーバーが自動的にブランチをビルドし、それをステージング サーバーにデプロイして手動で統合テストを行います。ビルドに満足したら、デプロイしたいと思います。しかし、git フロー ブランチ モデルでは、最初にマスターとタグにマージする必要があります。問題は、このマージの後に別のビルドとテスト サイクルを実行する必要があるか、それとも何ですか?
リリースが構築されたものとは異なる (技術的に) コミットを指すタグでマージしてタグ付けするのは奇妙に思えます。また、master に入った後で再ビルドするのも良くないように思えます。
私が思いついたオプションは次のとおりです。
- リリース ブランチでビルドしてから、マスター ブランチでマージ、再構築、テストします。
- リリース ブランチでビルドしてテストしてからマージし、新しいビルドが必要ないことを信頼します。
- git フロー モデルを変更して master にマージするステップを削除し、リリースするリリース ブランチの最終コミットにタグを付けるだけです。
- マスターにマージしないと何が失われますか?
- この場合、おそらくマスターで開発することができます