分支还是不分支？

Question

直到最近，我的开发工作流程如下：

1. 从产品所有者那里获得特性
2. 创建一个分支(如果功能超过1天)
3. 在分支中实现它
4. 将主分支的更改合并到我的分支(以减少向后合并期间的冲突)
5. 把我的分支合并回主分支

有时候合并会有问题，但总的来说我很喜欢。

但是最近，我看到越来越多的不创建分支的想法的追随者，因为它使得实践持续集成、连续交付等变得越来越困难。对于那些有着分布式VCS背景的人来说，这听起来特别有趣，他们谈论了Git、Mercurial等的伟大的合并实现。

所以现在的问题是我们应该使用树枝吗？

Answer 1

除非你们都是在同一棵工作树上工作，否则不管你们是否这样称呼他们，你们都在使用树枝。每次开发人员签入他的工作树时，他都会创建一个单独的本地开发分支，并且每次他签入时都会进行合并。对于大多数团队来说，问题不在于如果你使用分支，问题是有多少个，目的是什么？

真正做到“连续”集成的唯一方法是让每个人都在同一棵工作树上工作。这样，你就会立刻知道你的改变是否会对其他人产生不利影响。显然，这是站不住脚的。为了完成任何事情，您需要在分支中实现一定程度的隔离，即使“分支”只是您的本地工作目录。需要的是集成和隔离之间的适当平衡。

在我的经验中，使用更多的分支可以提高集成的程度，因为集成是与需要完成的人员一起完成的，而且每个人都可以根据需要更容易地隔离与非相关的问题。

例如，我花了最后一天在我们的构建中跟踪了最近引入的三个与集成相关的bug，这些bug阻碍了我的“真正”工作。在尽职尽责地把这些错误报告给需要修复的人之后，我现在是不是应该等到它们完成才能继续我的工作呢？当然不是。我创建了一个临时的本地分支来恢复这些更改，这样我就可以有一个稳定的基线来工作，同时仍然从上游接收最新的更改。

如果没有为此目的创建一个新分支的能力，我将被简化为三个选项之一:要么恢复中央回购中的更改，然后在我的工作树中手动维护恢复它们的修补程序，然后尝试不小心签入它们，或者在引入这些bug之前返回到某个版本。第一个选项可能会打破其他一些依赖关系。第二个选项是大量的工作，所以大多数人选择第三个选项，这在本质上阻止了您在修复之前进行更多的集成工作。

我的例子使用了一个私有本地分支，但同样的原则也适用于共享分支。如果我共享我的分支，那么可能有5个人能够继续执行他们的主要任务，而不是执行冗余的集成工作，这样就可以执行更多有用的集成工作。分支和持续集成的问题不在于您有多少分支，而在于您合并它们的频率。

Answer 2

如果您有几个团队同时处理不同的特性，那么您就无法省略分支。您应该与团队成员共享(部分实现)代码，防止其他团队获得尚未完成的功能。

分支是实现这一目标的最简单方法。

尽管缩短分支的生命周期并避免同时在两个分支中处理同一个模块是很好的，但是这样您就不会有冲突\合并问题了。

Answer 3

但最近，我看到越来越多的追随者的想法，不做分支，因为它使实践的持续集成，连续交付等越来越困难。

那么，对您来说，持续集成、连续交付等做法是否会使您更加困难呢？

如果没有，我认为没有理由改变你的工作方式。

当然，遵循正在发生的事情和当前最佳实践的演变是很好的实践。但是我不认为我们需要放弃我们的过程/工具/什么的，仅仅因为X(和/或Y和/或Z)说它们不再流行了:-)