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

Question

为了确保所有代码最终都通过pull请求代码审查，我们已经开始按照git-flow风格创建功能和bug分支的分支。

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

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

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

Answer 1

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

步骤详情如下：

1. 结帐发布/ 2017.05.24分支。 2017.05.24是发布分支的名称。
2. 执行branch命令并将其命名为“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

我处理它的方式是在发布分支上有一个修补程序分支。 修复错误后，我将合并到master / release分支，并合并到Dev分支，然后逐渐渗透到其他功能。

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

Answer 3

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