是否有一个gitflow进程用于分支和错误修复与发布分支？

Question

为了确保所有代码最终都通过拉取请求代码审核，我们已经开始为git-flow style之后的开发创建功能和错误分支的分支。

唯一的问题是，一旦在发布分支中发现错误，我们通常必须从发布分支创建一个分支，以便将pull请求发送回发布分支。但是当bug修复发布分支时，似乎没有一个明显的git-flow进程来处理发布分支的分支。

修复发布分支错误和代码审查的git-flow流程是什么？

您是否应该修复开发中的错误并创建新的发布分支？ 分支发布分支仍然是有效的git-flow？ 在发布分支错误修复上处理拉取请求代码审查的最佳方法是什么？

Answer 1

我刚刚遇到同样的问题。我建议从发布分支创建一个普通的分支。在那里进行修复并为该分支创建一个pull请求以合并到release分支。这是使用普通的分支和合并命令，而不是Git Flow命令。

以下步骤详情：

1. 结帐发布/ 2017.05.24分行。 2017.05.24是发布分支的名称。
2. 执行分支命令并将其命名为“release2017.05.24 - 修复原因”。这将显示分支存在的原因（用于发布修复）。
3. 进行更改，提交，将更改推送到服务器（将分支推送到源）。
4. 在您的服务器中为您的分支创建一个pull请求以合并到release / 2017.05.24分支。注意：合并到发布/ 2017.05.24分支不是默认值，因此请务必在创建拉取请求之前更改它。
5. 代码审核审核结帐“发布/ 2017.05.24”
6. 执行合并命令，在“release2017.05.24 -reason for fix”分支中选择提交。
7. 删除“release2017.05.24 - 修理原因”分支的本地和远程分支机构

希望这会更好。 Git-flow命令集中有很多步骤和制动，但应该允许拉动请求发生。

Answer 2

我处理它的方法是在发布分支上安装一个修补程序分支。修复bug之后，我会合并到master / release分支，并合并到Dev分支，然后逐渐渗透到其他功能。

然后会删除此修补程序，因为它将记录在master或dev中。

Answer 3

错误修复分支应该从master分支（或任何分支代表您的生产代码）。如果您正在使用git flow，这有时意味着如果您已经在开发分支中进行了代码更改，那么您必须选择提交到错误修复分支。