我一直在尝试配置TC安装以使用以下方案：
我们有多个开发人员并行处理多个错误。我们的源代码存储在github中，我们正在使用pull请求。我希望Teamcity触发一个基于拉取请求的构建，如下所述：http://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/这似乎很容易做到。不幸的是，看起来这样的配置不会合并拉取请求，而只是从存储库中提取它。
让我举个例子：
开发人员A打开拉取请求nr 1（基于代码版本0010）。开发人员B也基于代码版本0010打开拉取请求nr.2。存储库中的当前代码版本是0015.我们针对每个拉取请求的TeamCity服务器应首先检出源代码的版本0015，然后合并pull nr 1中的更改。如果此合并成功，那么它应该尝试编译代码。应该为pull nr 2做类似的事。
请注意，我需要TC与分支中CURRENT版本的代码合并，而不仅仅是从pull请求中提取版本。
审核并接受Pull request nr 1，并将其合并到生产存储库中。这应该触发重建拉请求nr 2，因为现在当前分支不是0015，而是0015，代码来自pull nr 1.
据我所知，对于许多拉取请求，每次合并都会触发大量的构建/重建。但这正是我需要的TC。持续集成过程的一部分应该是确保来自pull请求的源代码应该与当前头合并而没有任何冲突。
按照链接中的描述配置TC服务器后，它并不真正与HEAD合并，而只是执行git pull和compile。这根本没有用，因为这应该始终有效（前提是开发人员在提交更改之前在其计算机上编译代码）。
我很欣赏有关如何设置CI环境的任何提示或想法，我们可以针对最新代码测试实际合并，而不仅仅是简单的编译。
答案 0 :(得分：1)
TeamCity可以做到这一点。路线位于您指向的链接中：（https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/）
简而言之，使用+:refs/pull/*/merge作为分支规范，让TeamCity使用合并的PR分支。使用+:refs/pull/*/head只是在描述时构建未合并的分支。
答案 1 :(得分：0)
我不相信teamcity可以开箱即用。您可以通过制作自己的插件来实现它，但您可能最好使用webhook。
看看http://blogs.atlassian.com/2013/05/git-automatic-merges-with-server-side-hooks-for-the-win/它描述了类似的东西，并有一个脚本，你可以重新利用你的需要。
答案 2 :(得分：0)
TeamCity 8.1引入了自动合并功能，可在成功构建后将分支合并到另一个分支。
https://confluence.jetbrains.com/display/TCD9/Automatic+Merge