我们使用 TeamCity 进行持续集成，使用 Git 进行源代码控制。一般来说，它工作得很好 - 方便、现代并且在测试失败时有利于我们快速反馈。
有一个与 Git merge 细节相关的奇怪行为。以下是案例的步骤:
- 第一个开发人员从主存储库中提取数据。
- 第二个开发人员从主存储库中提取数据。
- 第一个开发人员在本地提交 A。
- 第二个开发人员在本地提交 B；
- 第二个开发人员推送提交 B。
- 第一个开发人员想要推送提交 A 但无法推送，因为他必须先 pull 提交 B。
- 第一个开发人员从远程存储库中 pull 。
- 第一个开发人员推送提交 A 并生成 merge 分支提交。
master repo 中的提交历史如下:
- B 第二开发者
- 第一个开发者
- 首先 merge 分支开发人员。
现在假设 Second Developer 在他的提交 B 中修复了一些失败的测试。
TeamCity 将执行以下操作:
- 提交 B 到达 - TeamCity 使构建 #1 并通过所有测试
提交 A 到达 - TeamCity 使构建 #2(没有提交 B)测试栏变为红色!
TeamCity 认为待处理的“merge 分支”提交不包含任何更改(任何新文件)- 但它实际上确实包含提交 B 的 merge ，因此 TeamCity 不想在这里进行新构建并使测试成为绿色。
这里有两个问题: 1. 在我们的例子中，我们在第二次提交(提交 A)中返回失败的测试 2. TeamCity 不想进行新构建并使测试恢复绿色。
有谁知道如何解决这两个问题。
我考虑一些合理的通用方法。
最佳答案
只是补充一下，我强烈建议使用 git pull --rebase，或者完全只做一个 git fetch，然后用 git log -p ^master origin/master 修改更改的内容，以确定我是否可以由于其他开发人员的工作而发生的事情。在这一点上，我可以将我的工作重新定位在远程更改之上，teamcity 不会给您带来您在此处看到的问题。这不是我围绕 teamcity 所做的事情，而是工作流的一部分，它允许更线性的历史记录和 merge 冲突解决方案，如果您正在 merge 以前的 merge ，则不必重新访问。
HTH,
亚当
关于java - TeamCity 和挂起的 Git merge 分支提交保持构建失败的测试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2561344/