为了确保所有代码最终都通过拉取请求代码审核,我们已经开始为git-flow style之后的开发创建功能和错误分支的分支。
唯一的问题是,一旦在发布分支中发现错误,我们通常必须从发布分支创建一个分支,以便将pull请求发送回发布分支。但是当bug修复发布分支时,似乎没有一个明显的git-flow进程来处理发布分支的分支。
修复发布分支错误和代码审查的git-flow流程是什么?
您是否应该修复开发中的错误并创建新的发布分支? 分支发布分支仍然是有效的git-flow? 在发布分支错误修复上处理拉取请求代码审查的最佳方法是什么?
答案 0 :(得分:2)
我刚刚遇到同样的问题。我建议从发布分支创建一个普通的分支。在那里进行修复并为该分支创建一个pull请求以合并到release分支。这是使用普通的分支和合并命令,而不是Git Flow命令。
以下步骤详情:
希望这会更好。 Git-flow命令集中有很多步骤和制动,但应该允许拉动请求发生。
答案 1 :(得分:1)
我处理它的方法是在发布分支上安装一个修补程序分支。修复bug之后,我会合并到master / release分支,并合并到Dev
分支,然后逐渐渗透到其他功能。
然后会删除此修补程序,因为它将记录在master
或dev
中。
答案 2 :(得分:0)
错误修复分支应该从master分支(或任何分支代表您的生产代码)。如果您正在使用git flow,这有时意味着如果您已经在开发分支中进行了代码更改,那么您必须选择提交到错误修复分支。