我最近一直在阅读有关continuous integration 的内容，并且可能会发生一种我不知道如何适当处理的情况。
我们有一个稳定的主线/主干分支，并为功能创建分支。每个开发人员都会通过定期从主干合并到他们的分支来保持他们自己的特性分支是最新的。但是，完全有可能在几周或几个月的时间内创建和处理两个或多个功能分支。在这个时候，可以部署许多版本的软件。这就是我产生困惑的地方。
一个功能分支的更改很可能会导致与其他功能分支的合并冲突。 CI 建议您至少每天合并到主干中，这样可以快速解决冲突。但是，您可能不想将功能代码合并到主干中，因为它可能尚未完成，或者您可能不希望该功能在下一个版本中可用。那么，您如何处理这种情况并仍然遵循日常代码集成的 CI 原则？
【问题讨论】：
现在有一些很好的资源展示了如何结合 CI 和特性分支。 Bamboo 或 Feature Branch Notifier 是一些查看方式。
this 是另一篇相当长的文章，展示了所谓分布式 CI 的优点。下面，摘录一段解释好处：
分布式 CI 具有持续部署的优势，因为它保持干净稳定的 Mainline 分支，始终可以部署到生产环境。在集中式 CI 过程中，如果代码未正确集成（损坏的构建）或集成了未完成的工作，则将存在不稳定的 Mainline。这对迭代发布计划非常有效，但会为持续部署造成瓶颈。从开发人员分支到生产的直接线路必须在 CD 中保持干净，分布式 CI 通过只允许将生产就绪的代码放入主线来做到这一点。
仍然具有挑战性的一件事是保持分支构建隔离，这样它就不会通过将其分支构建推送到它来污染您的二进制存储库。 Bamboo 似乎解决了这个问题，但不确定 Jenkins 是否那么容易。
【讨论】：
根据我在 CI 方面的经验，您应该按照其他人的建议使您的功能分支与主线保持同步的方式发生了变化。这一直在为我工作了几个版本。如果您使用颠覆，请确保您与合并历史启用合并。这样，当您尝试将更改合并回线时，它只会像您将功能更改合并到线一样，而不是尝试解决您的功能可能与主线发生的冲突。如果您使用更高级的 VCS，例如 git，第一个合并将是一个变基，第二个将是一个合并。
像Feature branches with Bamboo这样的工具可以帮助您更顺利地完成细化工作
【讨论】：
将功能分支提交回主线，并且经常是持续集成的基本功能。有关详细信息，请参阅This Article
【讨论】：
更全面地解释in this article 的想法是每天从主干/发布分支合并到功能分支，但只有在功能满足您对“完成”的定义时才在另一个方向合并。
由一个功能团队编写的代码在完成后将被推送到主干中，并将“分发”给其他团队，作为日常合并过程的一部分，在那里可以处理冲突。
这并没有满足 Nick 对可以用作备份工具的版本控制系统的渴望，除非所做的更改足够小，以至于它们可以在某个时间范围内提交到功能分支失去工作的风险是可以接受的。
我个人不会在完成之前尝试将代码重新集成到发布分支中，虽然我从未真正尝试过，但我确信为未完成的工作构建功能切换有其自身的问题。
【讨论】：
正确的 CI 中没有特征分支。请改用feature toggles。
【讨论】：
我认为他们的意思是将主线合并到功能分支中，而不是相反。这样，特性分支不会过多地偏离主线，并保持在易于合并的状态。
git 人员通过在提交功能之前在主分支之上重新设置功能分支来做同样的事情。
【讨论】：