理论上会不会出现， 2 个 pull request 都能通过测试，都不经修改直接 merge 后，反而通过不了测试？

会的，两个组合起来触发一个 bug 。
单个基于当前分支的修改都能过，两个一起会触发 bug 。
说明测试有没有 cover 到的 情况

a=1;
a= !a;
assert(a)

1.patch
- a=!a;

2.patch
- a=1;
+ a=0;

merge request 的测试必须要在当前版本上测。
你第一次 merge 以后，测试结果已经无效了，必须重新跑两遍测试才行。

你甚至可以要求原来的测试也能通过

a=True
b=True
assert a or b

a.patch
- a=True
+ a=False

b.patch
- b=True
+ b=False

现在好多开源项目，都是 pull request 隔好几周才 merge ，中间也有其它 pull request ， merge 前不会重新运行 CI ， merge 后看来还是有隐患的

一般 merge 后还会触发一次构建。

@9hills 刚才试了一下，至少 travis CI 的界面上确实会触发一次 build 的。
奇怪的是， Github 的 pull request 界面却没有地方会显示 merge 后那一个 build 的结果，显示的一直是 merge 前 build 的结果，页面上也没有跳过去的链接。
我之前一直都没注意到 merge 后那一个 build ，估计别人也不容易注意到 merge 后的结果。

@vghdjgh 是的，这个 merge 后的构建多数版本控制工具是不显示的。

但是假如构建系统和发布系统打通，那么发布系统上应该显示这个主干是不可发布的。

GitHub 等平台可以开项目设置，要求 PR 必须含有保护分支所有 commit （新），还可以要求必须通过指定测试，才可以 merge 回保护分支，就可以解决 lz 的问题

@Senorsen 你说的是保证 merge 前通过测试，我在讨论的是 merge 后的那次测试是不是也能通过、能不能保证一定通过。

我刚才发现， travis CI 会对 merge 后的那次测试结果提供 email 通知的，可以算是一种机制吧。

@vghdjgh 我是指，比如可以设置成这样，要求保护 master 分支，满足两个条件
1. 只有通过指导测试（如 travis-ci ）的 commit 才能合并到 master
2. 想合并到 master 分支的 PR ，必须没有 behind master 的 commit ，即合并前就保证 patch-1 分支与合并到 master 后的效果一致

通过同时应用两个规则，即保证 merge 后的代码也可以通过测试

上边一处 typo ： 指导测试 -> 指定测试

Require branches to be up to date before merging

@Senorsen 确实有这样的设置，选中“ Require status checks to pass before merging ”后才会显示这个选项

@vghdjgh 是的，没错～