4
Gitフローを簡素化するために開発ブランチを取り除く方法
継続的に開発されたWebプロジェクト（製品ではない）には、現在gitフローにほぼ基づいた次の分岐戦略があります。 開発ブランチ：最新の作業バージョン マスターブランチ：リリースされるバージョン/リリースされるバージョン 機能ブランチ：開発中の機能 ホットフィックスブランチ：リリースバージョンの緊急バグ修正 マスターは読み取り専用で、開発ブランチまたはホットフィックスブランチからのプルリクエストによって更新されます。各更新により、リリース候補が構築され、ステージングシステムに展開されます。リリース候補は、手動の承認後に実稼働に展開されます。 フィーチャーブランチはオフに基づいて作成されている開発、または最後のマスターにマージされたことにコミットから。開発する機能ブランチからのプルリクエストが構築され、統合テストと受け入れテスト（自動および手動）が実行される無料のテストシステムにデプロイされます。テストとレビューに成功すると、PRはマージされ、次のリリースの一部になります（開発からマスターへのマージ）。 私の目標 これを簡素化し、開発ブランチを削除したいと思います。開発ブランチには主に歴史的な理由があり、常に正常にテストされたバージョンであるため、マスターから切り離しておく必要はないと思います。これを削除すると、追加のマージがなくなるため、リリースプロセスも簡素化されます。 次の制約があります。 リリースは予定されており、完全に自動化するべきではありません 機能ブランチは通常短命ですが、一部は数週間マージされないままになります（たとえば、再設計）が、同様にテストする必要があります（現在、開発のためのオープンプルリクエストとして） 場合によっては、通常のリリース以外で単一の機能をリリースして、事実上それを修正プログラムに変更する必要があります。現在の戦略では、機能ブランチをリベースし、直接マスターにマージできます ステージングでの外部システムとの受け入れテストが失敗した後、機能を保留する必要があることも起こります 移行についてわからない場合： 現在、テスト用のプルリクエストを作成し、リリース用のコミットをマージしています。これを統合できますか？ マスターが最新リリースより前である場合のホットフィックスの処理方法。ホットフィックスブランチからリリースを直接ビルドおよびデプロイする必要がありますか？ 既にマージされたリリースから除外されるべき機能に対処する賢明な方法はありますか？これらの場合、独立した開発ブランチは本当に利点ですか？とにかく、ほとんどの場合、手動でコミットを元に戻して元に戻すことになります。