有没有适用于分支和错误修复的Gitflow流程，包括发布分支？

Question

为了确保所有代码最终都经过拉取请求代码评审，我们开始按照git-flow风格从develop分支创建功能和错误分支。

唯一的问题是，一旦在发布分支中发现错误，我们通常必须从发布分支创建一个分支，以便向发布分支发起拉取请求。但是，在修复发布分支错误时，似乎没有明显的git-flow处理分支的过程。

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

您是否应该在develop中修复错误并创建新的发布分支？ 从发布分支创建分支仍然是有效的git-flow吗？ 如何最好地处理发布分支错误修复的拉取请求代码评审？

- Mark Rogers

Answer 1

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

以下是步骤详细信息：

1.检出发布/2017.05.24分支。其中2017.05.24是发布分支的名称。 2.执行分支命令并将其命名为“release2017.05.24 - reason for fix”。这将明确表明分支存在的原因（用于发布修复）。 3.进行更改，提交，将更改推送到服务器（将您的分支推送到origin）。 4.在您的服务器上，为您的分支创建拉取请求，以将其合并到发布/2017.05.24分支中。注意：合并到发布/2017.05.24分支不是默认设置，因此请在创建拉取请求之前确保更改它。 5.在代码审查批准后，检出“发布/2017.05.24”。 6.执行合并命令，在“release2017.05.24 -reason for fix”分支中选择您的提交。 7.删除您的“release2017.05.24 - reason for fix”分支的本地和远程分支。

希望这样做会更好。有很多步骤和Git-flow命令集中的断点，但应该允许拉取请求发生。

- smurphy

---

加1 - 这就是我做的事情，除了特殊命名之外，我只希望有一种官方的gitflow方式来做到这一点。 - Mark Rogers

Answer 2

我处理的方式是创建一个热修复分支，从发布分支分支出来。修复完毕后，我会将其合并到主分支/发布分支，并合并到Dev分支，然后再向其他功能传递。

热修复分支将被删除，因为它已经记录在master或dev中。

- Mike Tung

---

这对于一个在主分支中尚不存在的新功能来说是没有意义的。 - smurphy

功能将从dev分支出来，一旦完成就会合并回dev，当在dev中积累了足够的功能时，它将作为发布版本合并到master中。 - Mike Tung

@smurphy 一个新功能不会是来自早期版本的热修补/错误修复。像Mike建议的那样，新功能将来自开发并作为新版本发布。 - HankCa

@MikeTung提到了将热修复更改合并到开发分支的好处，这是个不错的观点。您认为每次在热修复版本之后的每个版本都应该引起一个新的发布吗？我在考虑安全补丁 - 答案是肯定的。您觉得这有道理吗？ - HankCa

Answer 3

Bug修复分支应该从主分支（或代表生产代码的任何分支）派生出来。如果你正在使用git flow，有时这意味着你必须将提交的更改挑选到bug修复分支中，如果你已经在从develop分支创建的分支中进行了代码更改。

- Joe Phillips

---

所以基本上，您需要从develop分支创建一个常规的错误修复gitflow分支，然后在经过代码审查并合并到develop分支后，再将其挑选到发布分支中？ - Mark Rogers

不，我只有在已经在分支中修复了错误之后才将其声明为“热修复”。如果我仍然需要修复错误，我会从主干上创建一个专门用于修复该错误的新分支，并使其与常规发布不同步。 - Joe Phillips