好的，所以我已经看过很多这类问题而没有任何答案，而是警告它。所以我理解为什么这样做可能会令人烦恼/危险，并考虑过这些事情。但是我的团队项目/管理是如何设置的（至少目前为止），当有人提交并且Jenkins检测到，拉动和构建/时，能够撤消对BitBucket的提交对我们来说很有意义。测试失败。有没有插件/方法可以做到这一点？
答案 0 :(得分：1)
很容易从分支中删除HEAD提交但是，由于某些原因，你真的无法在jenkins工作中安全地执行此操作。
第一个原因是您可能没有处理单个提交。根据jenkins的配置方式（ex with a wait perioud），单个jenkins作业可能包含多个提交。此外，用户可能一次推送多次提交。
其次，当Jenkins完成执行时，无法保证启动Jenkins的提交仍然在HEAD。所有这一切都需要有人在Jenkins执行期间推送，现在你必须尝试更复杂的rebase，这可能是没有人工干预的可能（特别是因为默认情况下你不能自动重新定义合并提交）。
我的强烈建议是，不要试图从master / develop分支中删除提交，而是考虑采用gitlabs之类的东西负责合并到master中的模式。然后，您可以在jenkins中设置多分支管道作业，自动构建分支并配置gitlabs以防止合并，只要jenkins作业失败。这个想法是你为每个任务创建一个分支，然后jenkins将master合并到你的分支中，并在你提交pull请求时构建它。只有在此构建成功后才允许合并到master。
答案 1 :(得分：0)
如其他答案中所述，它比之前检查更容易。
实际上，还有另一个想法。它基本上重复了手动合并。如果有人成功实施它并分享他们的经验，那就太好了。
master。 （*）master-rc，这始终是master的快进内容。在评论和一些预检之后，它们可以直接推动合并开发商的拉动请求。 （**）A获取特定提交master-rc，并测试它是否构建，测试通过等。master被快速转发到A。然后返回第3步master-rc将重置为master，并且有关此故障的作者会收到有关失败的通知。然后返回步骤3.（***）这样，你总是可以确保master可以构建 - 因为它已经构建了。
（*）除特殊情况外，应取消正在进行的构建，并将master-rc重置为新的master，如果出现错误。或者，如果你需要这个，那么你的master就会被破坏，你应该停止步骤2-6直到它被解决。
（**）有一个选择 - 要么他们独立于构建周期而做，并且总有一些新内容可能超过master-rc - 请参阅下一个项目。或者他们等到周期开始。当有拉请求时，后者更方便，可以根据需要自动合并，并且它被批准合并。
（***）如果master-rc中的内容多于失败的内容，则可以将其与失败的内容一起丢弃，以便作者可以对其进行重新定位。或者自动重新定位，但这已经有些复杂了。