团队中Gitflow发布分支的限制

Question

我很高兴能够找到关于我的quastion的全面答案。这里是：

在我的团队中，我们使用gitflow作为开发和发布项目的工作流程。现在我们对gitflow有一个概念性的问题。

当我们决定发布时，我们推动我们的工作发布分支，QA和客户测试代码并响应一组错误或更改当前功能的请求（没有像gitflow建议的新功能）。

问题是，当我们想修复错误时，因为我们需要像团队一样工作，很多人应该在同一个发行版分支上工作。因此，无论我们是通过努力工作还是面临冲突问题，还是我们必须工作相应的工作效率都不高。

我们的想法是在发布和并行处理这些分支上创建新分支，但我们仍然认为这不是实现这一目标的最佳方法。

让团队在发布分支上平行工作以修复错误的最佳方式是什么？

Answer 1

这里显然没有对或错，但我建议你让QA &客户独立测试功能分支。这样每个测试会话的范围就会小得多并且更容易处理，并且您可以解决任何问题而不会与其他分支发生冲突。一旦您的分支已经过测试和修复，您可以将其移至发布分支。

Answer 2

这可能不是你正在寻找的答案，但对我来说，git流程方法的一个重要部分是，所有分支和合并（通过某种审查过程/拉请求）。

由于这个原因，我肯定会推荐你分支你的发布分支并合并回去。从不分支的一个显而易见的问题是，如果没有人执行读取和检查，您没有执行审查（如拉取请求）的步骤，此时提交已经在您的发布分支中（坏！）。此外，你可以有两个人提交并推送一次，等等等等

说了这么多，我知道这可能不是与git的流动过程完全贴合在特性和错误修正从develop从develop支，发布和来自master的修补程序，但您还应该记住，git流程实际上只是一个概念，指导和适应的思维模式。命令行工具只是为了帮助你。

例如，在我目前的工作中，我们开始尝试在纯度上使用git flow（并且我们与你有类似的声音场景），并发现我们最终使用了这些概念，但是在GitHub中管理自己的分支和合并拉取请求而不是您的标准git flow feature finish类型方案。我们这样做的主要原因是，以避免多位开发人员同时完成并推出一项功能。

我希望这可以帮助你。