我们有一个TeamCity 7.1安装，可以从GitHub存储库构建所有分支。
GitHub有一个通知挂钩回TeamCity以触发签入时的构建。我们还每隔120秒让TeamCity轮询GitHub以检查更改（如果在签入更改时服务器处于脱机状态）。
我们的正常发展遵循一个共同的模式：
所有东西都在游泳（在经过多次搜索以获得正确的配置设置之后）但是......
上述过程触发了TeamCity上的几个构建，我想知道它们是否都是必需的。通常情况下，我们最终会：
当然，第一个版本是特定分支上的最后一个版本，第二个版本是拉取请求，但第三个版本是什么？
答案 0 :(得分：13)
第三个构建实际上是最有价值的 - 它是拉请求自动合并的结果（当你按下github上的按钮时会发生合并）。
答案 1 :(得分：3)
您的构建似乎是多余的。在git中组织TeamCity构建功能分支的更节俭的方法如下：
refs/heads/master分支的持续集成。 120秒的民意调查在这里非常合理。refs/heads/feature-name分支组织夜间构建。根据我的经验，只有少数功能分支需要120秒轮询。 TeamCity 7.1为自动触发功能分支提供了非常好的功能，因此可以使用refs/heads/feature-*之类的分支掩码通过几次单击设置步骤（2）。
构建拉取请求没有任何意义，因为它们将被主版本覆盖。
答案 2 :(得分：0)
更新的答案，以防万一仍然有人使用TeamCity?
自2018年以来，有一个本地Pull Request Build Feature。与使用分支触发器和过滤器相比，这是一个更好的解决方案，因为它在内部版本和相应的PR 之间创建了双向链接，并且使您不必向列表中添加任何refs/pull/... VCS分支规范。
不过，如果您坚持使用pull/*/merge：请注意，这会创建多余的构建，以防万一“ 需要线性历史记录”（=仅允许“ Rebase＆在GH回购中启用了从PR合并南瓜）功能，因为在这种情况下，PR只能在其基础分支保持最新状态后才能进行合并。