多个功能分支和持续集成

Question

我最近一直在阅读关于continuous integration的一些内容，并且有一种情况可能会发生，我不明白如何正确处理。

我们有一个稳定的主干/中继分支，并为功能创​​建分支。每个开发人员将通过定期从主干到其分支合并来保持自己的功能分支最新。但是，完全有可能在几周或几个月的时间内创建并处理两个或更多个功能分支。在这个时候，可以部署许多版本的软件。这就是我的困惑所在。

一个功能分支的更改很可能会导致与其他功能分支的合并冲突。 CI建议您至少应每天合并到主干中，以便快速解决冲突。但是，您可能不希望将功能代码合并到主干中，因为它可能尚未完成，或者您可能不希望在下一版本中提供该功能。那么，您如何处理这种情况并仍然遵循日常代码集成的CI原则？

Answer 1

适当的CI中没有功能分支。请改用feature toggles。

Answer 2

更充分地解释的想法in this article是每天从主干/发布分支​​合并到功能分支，但只有在功能符合您的“完成”定义时才会向​​另一个方向合并。

一个功能团队编写的代码一旦完成就会被推入主干，并且将作为日常合并过程的一部分“分发”给可以处理冲突的其他团队。

这并不能满足Nick对可以用作备份工具的版本控制系统的需求，除非所做的更改足够小以至于可以在时间范围内将其提交到功能分支。失去工作的风险是可以接受的。

我个人并没有尝试在完成之前将代码重新集成到发布分支中，虽然我从未真正尝试过，但我确信构建功能切换为未完成的工作有其自身的问题。

Answer 3

我认为他们的意思是将主线合并到功能分支中，而不是另一种方式。这样，功能分支不会过多地偏离主线，并且保持在易于合并的状态。

在提交功能之前，git人员通过在主分支上重新定位功能分支来做同样的事情。

Answer 4

根据我对CI的体验，您应该像其他人所建议的那样，使您的功能分支与主线保持同步。这一直是我的几个版本。如果您使用的是subversion，请确保与合并历史记录启用合并。这样，当您尝试将更改合并到行时，只会将要素更改合并到行，而不是尝试解决您的功能可能与主线有关的冲突。如果您使用更高级的VCS（如git），则第一次合并将是一个rebase，其中第二个将是合并。

有些工具可以帮助您更顺利地完成这些Feature branches with Bamboo

Answer 5

现在有一些很好的资源显示如何结合CI和功能分支。 Bamboo或Feature Branch Notifier是一些值得关注的方式。

this是另一篇很长篇文章，展示了所谓的分布式CI的优点。下面，一段摘录解释了这些好处：

  

分布式CI具有持续部署的优势，因为它可以保持干净稳定的Mainline分支，始终可以部署到Production。在集中式CI过程中，如果代码未正确集成（损坏的构建）或者集成了未完成的工作，则将存在不稳定的主线。这在迭代发布计划中非常有效，但却为持续部署创建了瓶颈。从开发人员分支到生产的直接线必须在CD中保持清洁，分布式CI通过仅允许将生产就绪代码放入主线来实现。

仍然可能具有挑战性的一件事是保持分支构建是孤立的，这样它就不会通过将分支构建推送到它来污染你的二进制文件库。 Bamboo似乎解决了这个问题，但不确定詹金斯是否容易。

Answer 6

功能分支返回到主线，OFTEN是持续集成的基本功能。有关详细信息，请参阅This Article