テスト段階で発生したバグを修正するために、別のブランチが必要ですか？
Webアプリケーションであるソフトウェアの新しいバージョンをリリースする前に、私の会社はreleaseブランチを作成しています。 QAチームはそのブランチをテストし、いくつかの問題を報告します。開発者は修正コードをそのreleaseブランチにコミットする必要がありますか、それとも後でbugfixブランチにマージされる新しいreleaseブランチにコミットする必要がありますか？
詳細については、私の会社は現在gitflowモデルの変更バージョンを使用しています。 2週間ごとに新しいバージョンをリリースします。 featureブランチは、リリースプロセスの開始時にdevブランチにマージされず、releaseブランチにマージされます。開発者はreleaseブランチに修正コードをコミットして、QAチームによって提起された問題を修正します。これらのコードにより、新たな問題が発生する場合があります。これが、別のbugfixブランチが必要だと思う理由です。
bugfixブランチは、releaseブランチのテストから発生したバグの修正をすべて収集します。すべてのバグが修正された後、bugfixブランチはreleaseブランチにマージされ、QAチームはreleaseブランチのテストを再開します。修正するバグがなくなるまで、releaseブランチを数回テストできます。
私が正解した場合、次の問題があります。
- 新しいバージョンがデプロイされる前のリリースブランチは、現在すべての修正を収集している唯一のブランチです。新しい修正（特に、以前の修正によって引き起こされた問題に対する修正）を追加したい開発者は、開発ブランチでこれを確実にテストできません。その時点で、以前に行われた修正開発ラインに統合されません。
- したがって、現在、チームがこれらの問題を修正する唯一の方法は、現在のリリースブランチをチェックアウトし、そこに新しい修正を追加してローカルでテストしてから、リリースブランチにコミットすることです。もちろん、これはQAチームに適切に伝えられるべきですが、それでも、現在のQA作業に干渉するリスクがあるかもしれません。
追加のバグ修正ブランチを導入すると、QAチームへの修正の即時配信を延期できます。これには長所と短所があります。プロ側では、
- それはあなたの開発者がローカルでだけでなく前に統合された修正をテストすることを可能にします彼らはQAに行きます
- これにより、チームは修正を「リリース」にマージし、より適切に制御された時点でそれらをQAに配信できます。これにより、「移動ターゲット」であるWebアプリの認識が低下する可能性があります。いくつかの修正を収集すると、QAチームは2日ごとに修正の新しい「バンドル」を取得してテストできます。
コン側では、
- この追加のブランチを管理し、そこでの変更が「リリース」に入ると、追加のマージ手順が必要になります
- qAチームは修正が完了してもすぐには取得しません。
ただし、「バグ修正」ブランチを使用しない場合でも、QAチームがローカルコピーにすぐに修正をプッシュするとは限りません。 2日ごとに修正の「バンドル」が必要な場合、修正を入手するために「リリース」のローカルコピーを更新するまで2日間待つだけです。違いは次のとおりです。バグ修正ブランチを使用すると、開発者がより適切に制御できるようになります。リリースブランチのみを使用すると、制御はおそらくQA側により多くなります。
それらの長所と短所を比較し、これらの2つのアプローチのどちらがチームに適しているかを自分で決定します。
Gitflowは、リリースブランチに直接コミットすることを推奨しています
この[リリース]ブランチには、バグ修正、ドキュメント生成、およびその他のリリース指向のタスクのみを含める必要があります。
ただし、リリースブランチで作業している複数の開発者がいる場合、「リリース機能ブランチ」を作成することは理にかなっています。
ただし、リリースブランチで多くの作業を行っているこの位置にいる場合は、開発ブランチが最初に終了したかどうかを自問する必要があります。ほとんどの場所では、リリースを作成する前、または次の機能セットに進む前に、開発ブランチでQAを行っています。
ブランチには、共有ブランチと独自ブランチの2種類があります。この場合、リリースブランチはリリースまでの共有ブランチです。多くの人がそれに依存しているため、共有ブランチの状態をクリーンに保つことが重要です。また、新しいブランチを作成すると、独自に開発、テスト、リリースできる柔軟性が得られます。捨ててやり直すこともできます。
上記のケースでは、バグを修正してテストし、問題がなければリリースブランチにマージします。お役に立てれば。
リンク： https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- 更新 -
リリースブランチに修正を段階的に追加するか、1つのブランチの下にすべてを追加してリリースするかは、テスト戦略に依存します。 gitはコミットと変更を元に戻すのにあまり友好的ではないため、単一の大きなブランチを管理するのは難しくなる可能性があります。 Gitには、分岐戦略やワークフローは含まれていません。何が機能するかを選択するのは私たち次第であり、多くの大企業がいくつかのワークフローを公開しています。ほとんどの場合、私はgit-flowまたはGitHubワークフローを使用することを好みます。