使用Gitflow的长期存在的分支

五年前，我们强调了使用Gitflow的长期存在的分支．从本质上说，长期存在的分支与持续集成所有对源代码的更改是相反的，根据我们的经验，持续集成对于大多数类型的软件开发是更好的方法。后来我们把谨慎扩展到Gitflow它本身，因为我们看到团队几乎只在长寿命的分支中使用它。今天，我们仍然看到团队处于这样的环境中:基于web的系统的持续交付是被吸引到长期存在的分支的既定目标。所以我们很高兴Gitflow的作者现在在他的文章中增加了一个注释原文，解释说Gitflow不是为这样的用例设计的。

Gitflow是使用Git的版本的严格分支模式。虽然不是一个固有的坏模式，但我们经常看到它被滥用。如果特性和开发分支的寿命很短，并且经常合并，那么您实际上是在使用Git的强大功能，它使这些活动变得很容易。然而，我们经常看到的一个问题是，这些变成长寿的分支，这会导致可怕的合并冲突，许多人开始使用Git来逃避。合并就是合并。不管您使用的是什么源代码控制工具或模式。如果您等待合并超过一两天，您可能会遇到一个大的合并冲突。如果你有一个更大的团队，这就会成为一个真正的问题。如果你有超过几个人等待合并，你可能会有一个严重的瓶颈。引入像Gitflow这样的模式需要经常进行合并才能成功。因此，务必使用该模式，但前提是您有防止长寿命分支的规程