Git流是否适用？我认为git flow在发布前合并到master的步骤上存在缺陷

大多数使用git流的人在开发了如下特性之后会指导发布过程

合并

功能

分支进行开发

从

develope

在

release

分支上启动QA，并提交

release

分支以修复QA中的问题。它还意味着

发行版

版本源代码运行在QA环境（又名.beta）上

将

release

分支合并到

master

分支，并在QA后将

version

标记到master分支

如果生产环境中存在错误，则从

主
分支创建
修补程序
分支

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

有人可以说，潜在的冲突应该已经在

发布

分支上得到解决，以继续将最新的

开发

分支合并到

发布

分支。

develope

分支包含最新的其他发行版本

但这种说法是荒谬的。根据我的经验，在一个特性的QA过程中，合并其他特性是不可接受的。甚至不可能一次又一次地合并。在这种情况下，不可能一次又一次地将

开发

分支合并到

发布

分支。然后，从

发布

分支到

主

分支的合并将产生许多冲突。之后，解决冲突的手动工作可能会产生QA中未发现的其他错误。合并到

master

分支后立即进行标记是草率的

我的公司通常在beta QA之后进行生产环境QA，这是使用

发行版

分支完成的。在这种情况下，可能会产生这么多修补程序分支，不是吗？不仅如此，我认为hotfix这个名称不适合这种情况，因为它实际上并没有在production env QA之前发布

[我的想法和建议]

从这个上下文来看，我认为应该在

release

分支上进行发布，并对其进行标记。因为

发布

分支在QA期间经过验证，并且将其合并到另一个分支时没有潜在的bug

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

[问题]

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

---

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

我在前一位雇主用了大约一年的时间处理git flow，我不记得在将版本合并到master中时有任何冲突。在

master

中完成的任何热修复程序也应该出现在开放版本中，否则这些发布分支仍然会有热修复错误。。。你能详细说明一下什么情况会产生这样的冲突吗？你的陈述

将开发分支合并到发布分支
是不正确的。使用
git-flow
时，您不会将
develop
分支合并到
release
。您可以从
develope
创建
release
分支。当
发布
完成时，分支被删除。只有两个长期存在的分支具有
git-flow
模型（
master
和
develope
），这一事实减少了合并冲突的源数量。但是如果你想让你的
发行版
分支始终处于“活动”状态，并在那里和那里进行合并，那么当然会发生冲突。@kosist谢谢。您的解释让我了解了git流的优点。我在上面描述的方法，使太多的活分支，年复一年。我花了大约一年的时间与git流在我的前雇主，我不记得有任何冲突合并到主版本。在
master
中完成的任何热修复程序也应该出现在开放版本中，否则这些发布分支仍然会有热修复错误。。。你能详细说明一下什么情况会产生这样的冲突吗？你的陈述
将开发分支合并到发布分支
是不正确的。使用
git-flow
时，您不会将
develop
分支合并到
release
。您可以从
develope
创建
release
分支。当
发布
完成时，分支被删除。只有两个长期存在的分支具有
git-flow
模型（
master
和
develope
），这一事实减少了合并冲突的源数量。但是如果你想让你的
发行版
分支始终处于“活动”状态，并在那里和那里进行合并，那么当然会发生冲突。@kosist谢谢。您的解释让我了解了git流的优点。我上面所描述的方法，一年又一年地制造了太多活的分支。