分支机构中断持续集成吗？

我认为这篇文章《成功的Git分支模型》在经验丰富的DVCS用户中是众所周知的。

我hg主要使用它，但是我认为这种讨论对任何DVCS都适用。

我们当前的工作流程是每个开发人员克隆主存储库。我们在自己的本地仓库上编写代码，运行测试，如果一切顺利，则推送给主服务器。

因此，我们希望设置诸如Jenkins的CI服务器，并通过将来的预配系统（厨师，木偶，ansible等）改善我们的工作流程。

实部

好了，以上介绍的模型很好用，但分支机构可以破坏CI。Feature分支应该与原点同步（根据文章，它将是development分支），以使CI和合并更加顺利，对吗？

说爱丽丝和鲍勃正在研究两个功能。但是爱丽丝第二天就完成了。鲍勃的功能需要一个星期。到Bob完成时，他的更改已过期（也许Alice重构/重命名了某些类）。

一种解决方案是，每天早晨开发人员必须master/origin检查是否有任何更改。如果Alice提交了，Bob应该拉入并合并到他的工作区中，以便他的功能分支是最新的。

1. 这是个好方法吗？
2. 这些分支是否应该存在于主存储库中（不是本地克隆？），这意味着每个开发人员都应向GitHub / Bitbucket上的主存储库授予特权，以便他们可以创建新分支吗？还是在本地完成？
3. 最后，如果分支未与同步，则本文介绍的模型应打破CI origin/master。既然我们要进行夜间构建，开发人员是否应该在离开工作之前进行合并和合并，并且CI也要在每个功能分支上运行？

首先，使用功能分支（隔离功能完成的工作）和CI（在提交集成问题后立即查找集成问题）的用法有些矛盾。

我认为，在要素分支上运行CI是浪费时间。随着功能分支的频繁出入，CI工具必须一遍又一遍地重新配置。对于最有可能仅从一个或两个来源获取更新的分支机构，该更新协调其签入，以避免CI系统本应检测到的问题。
因此，在主资源库服务器上具有功能分支也是没有意义的。

对于问题1和问题3：开发人员有责任确保在将主功能分支合并到主开发分支时不中断其构建。他们如何做到这一点是他们的问题，但是两种可能的方式是：

• 定期（例如每天）将对主开发分支所做的更改拉入功能分支
• 完成功能后，将主开发分支合并到功能分支，然后将合并结果推送到主开发分支。

无论哪种情况，都可以发现明显的集成问题（例如，重命名的类/文件），并首先在功能分支上进行修复。仅当夜间构建运行时才发现更细微的问题，应在此之后修复。

回应1）

任何可行的方法都是一个好方法。但是：持续集成的整个前提是整合不断。这个想法不仅是要尽早发现集成错误，而且要在开发反馈周期之内-即在测试代码的所有细节都在开发人员的短期记忆中。这意味着，在通常的日常情况下，每次提交时都必须跨功能分支集成工作-可能每15分钟左右一次。重申一下：持续集成的主要目的是在所有细节都在进行更改的开发人员的短期记忆中暴露出集成错误。

2）

通常，分支是通过克隆存储库在Mercurial中创建的，因此您无需向每个开发人员授予对主存储库的提交特权。但是，您可能希望使开发人员能够在连续集成服务器上创建克隆的存储库，因为在本地运行测试并不总是可行的。（我曾经有一个CI系统，其中的单元测试在128个核心集群上运行需要8个小时）-不用说，开发人员没有，不能在本地运行测试。

3）

如果您有足够的计算资源，可以，开发人员应该始终保持最新的开发主线，尤其是在他们离开工作之前，并且应该在所有开发线上进行通宵测试（尽管大多数CI系统不要轻易做到这一点）。

这是您可以执行的操作：功能分支。

1. 对于任何新任务（错误修正，功能等），请启动一个新分支（例如bugfix-ticket123-the_thingie_breaks）
2. 在工作时，不断更新默认值（或git中的master）并将其合并到功能分支中。这可以帮助您更新分支，而不必使用默认分支
3. 当功能准备就绪并且单元测试通过后，再次将默认值合并到分支中，关闭分支并在不合并的情况下推送它，集成商将注意到新的头并且它是一个封闭的分支，因此他/她将负责整合它。如果没有集成器，请切换到default并将功能分支合并到default中。

这里重要的是，将功能分支合并到默认分支中时，默认分支中的冲突为0，并且所有测试都通过。

通过这种简单的工作流程，您将始终拥有原始且稳定的默认分支，现在对发布分支也是如此，但是从default集成。如果您需要将修补程序直接集成到发行分支中，则仍然可以通过跳过默认分支来做到这一点，但是同样，请仅选择刚刚从目标分支更新且没有冲突且分支测试通过的分支。