git - Git-flow 适用吗？我认为 git-flow 在发布前合并到 master 的步骤存在缺陷

Question

大多数使用 git-flow 的人在开发如下功能后会指导发布过程。

1. 合并feature分支进行开发
2. release从_develop
3. 在分支上启动 QArelease并将 QA 的修复提交到release分支。这也意味着release版本源在 QA 环境（又名 beta）上运行
4. QA 后将分支合并release到master分支并标记version到 master 分支。
5. 如果生产环境中存在错误，hotfix则从分支创建分支。master

我认为第 4 步是有害的，因为其中有一个解决冲突的步骤。在解决冲突期间，可能会出现错误。

有人可以说，应该已经在release分支上解决了潜在的冲突，以继续将最新的分支合并develop到release分支。该develop分支包含最新的其他发行版本。

但这种说法是荒谬的。根据我的经验，在 QA 一个功能期间不能接受合并其他功能。甚至不可能一次又一次地合并。在这种情况下，不可能一次又一次develop地将分支合并到分支。release那么，从release分支到master分支的合并会产生很多冲突。之后，解决冲突的手动工作可能会产生其他在 QA 中找不到的错误。合并到master分支后立即标记是仓促的。

release我的公司通常在使用分支完成的 beta QA 之后进行生产环境 QA 。在这种情况下，可以产生这么多的hotfix分支，不是吗？不仅如此，我认为这个名称hotfix不适合这种情况，因为它实际上并没有在生产环境 QA 之前发布。

[我的想法和建议]

在这种情况下，我认为发布应该在release分支上完成并标记它。因为release分支在 QA 期间经过验证，并且没有将其合并到另一个分支的潜在错误。

有人会说你会得到太多的分支。如果我在提交上标记它并删除分支并不重要。

[问题]

如果我的想法是错误的或有缺陷，请让我知道并理解为什么 git-flow 更好或完美无缺。

如果您同情我的背景或同意我的想法，还有更好的主意吗？

标签： gitgit-flow