git-flowのリリースブランチのバグ修正であるブランチにどのように名前を付けますか？
すべてのコードが最終的にプルリクエストコードレビューを通過することを確認するために、git-flowスタイルに従って、機能のブランチとバグブランチの作成を開始しました。
唯一の問題は、リリースブランチでバグが見つかったら、リリースブランチへのプルリクエストを実行するために、リリースブランチからブランチを作成しなければならないことがよくあります。しかし、リリースブランチをバグ修正する際に、リリースブランチ以外のブランチを処理するための明らかなgit-flowプロセスはないようです。
リリースブランチのバグとコードレビューを修正するためのgit-flowプロセスは何ですか？
開発のバグを修正して新しいリリースブランチを作成することになっていますか？リリースブランチからのブランチはまだ有効なgit-flowですか？リリースブランチのバグ修正に関するプルリクエストコードレビューを処理する最良の方法は何ですか？
アップデートから、製品にデプロイされていないリリースについて質問しています。私はそれがあなたがまだマスターにマージしていないか、コミットにタグを付けていないことを意味すると思います。
Git-flowでは、リリースブランチで直接バグを修正します。以下の図を参照してください。
git-flow docs 明示的に読みました
問題はリリースブランチで直接修正されます
根拠は、これらのバグはリリースに関連する小さなものであるべきであり、バグ修正ブランチを回避することでリリーステストサイクルが改善されるということです。理論的根拠は健全ですが、コードベースが保護されていることを確認する方が良いと思います。リリースはドアを開ける必要があるため、コードレビュープロセスは覆されるべきではありません。コードレビューポリシーがあるので、私はあなたが既に行っていることを正確に行うことをお勧めします。ドキュメントの内容に関係なく、リリースブランチからバグ修正機能ブランチを作成し、バグ修正ブランチにコミットし、バグ修正ブランチからリリースブランチにPRを送信します。結局のところ、ブランチ戦略は、逆ではなく、ニーズに合わせて調整する必要があります。