像Git Flow这样的合并策略真的是一种反模式吗？

我的公司正在使用Git，并且正在使用一种特殊的分支方案-工作是在master中完成的，分支保留用于发布。只要在迭代中完成的所有工作都可以进入分支，就可以很好地工作，但是，如果出现关键的生产问题，我们必须确保将工作以某种方式进入两个分支。

最近，我们在那些分支机构中获得了一些“乐趣”。这一直是管理上的头疼事，要确保所有工作都进入每个分支，并且某个分支上已修复的一些错误只有在有人指出时才成为主要问题。

我前段时间遇到了Git Flow，我觉得这将解决我们的问题-代码不会一直渗透到发行版中，也不会渗透到整个发行版中。唯一的收获是我的领导说这种发展是一种反模式-疯狂发展了两个星期，然后花了三个星期来解决合并冲突。

我不确定自己是否同意，并且自提出以来，工作恢复正常了。直到最近，我们才有了一些重大的痛点。

我想知道-为什么将这种开发方案视为反模式？ 是真的反模式？

他主要是指模型的要素分支。功能分支很久以前被宣布为反模式，当时分支持续了几个月，版本控制系统无法合并以挽救生命。持续一两周的功能分支的问题要少得多，尤其是在此期间您不断地从 develop功能分支合并到此功能分支时。仍然建议不要超过此长度的任何内容。

即使您没有使用git flow的功能分支，其他部分也可用于确保您进行清晰的合并，并且将更改沿正确的方向传播。

合并是一件有趣的事情-合并的频率越低，难度越大，难度就越大，人们对其恐惧的程度就越大，他们执行的频率就越低。

解决方法是要么不允许分支偏离太多，要么不使用分支。

如果人们理解了这一点，那么合并可能就不会有太多问题，如果不是的话，可能是分支机构如果没有经过一定的培训就不是一个好主意。