我正在尝试完成一个完整的CI解决方案，它将从PR开始， - ＆gt; build - ＆gt;，build将nuget包推送到章鱼 - ＆gt;章鱼识别新包装和部署。我想要一些关于Pull Request策略如何用于自动构建拉取请求的说明。我们选择了“当团队成员创建或更新拉取请求到”dev“分支时，对此构建进行排队：MyCoolBuilDefinition”。
我注意到，一旦创建PR，构建就会立即触发。它创建了一个临时git分支“refs / pull / 123 / merge”。我假设它在这个分支上创建了一个预合并来进行构建。这是我们可以部署和测试的构建吗？或者这只是为了满足构建策略？
我担心如果有3个拉取请求被创建....如果PR1和PR2已经构建但未标记为已完成。 PR3的版本是否包含来自PR1和PR2的代码？因为当PR标记为已完成时，代码仅合并到“dev”分支......我想不会。预合并应该从最新的“dev”分支进行预合并。并且，如果P1和p2未标记为已完成，则P3将不具有P1和P2代码。
答案 0 :(得分：3)
构建仅用于满足构建策略，您的关注是正确的。预合并不包括其他未完成拉取请求的更改。它只是确保可以成功构建当前拉取请求。所以最好为“dev”分支创建两个构建定义。一个定义只是构建满足pull请求的代码，另一个定义允许持续集成并构建代码并推送nuget包。