在拉取请求期间，Github 在 "feature branch code" 上运行 "Junit" 检查，而不是在 "After merged like code"

Question

我在每个 github 拉取请求上设置了运行的“Junit/integration”测试。

现在考虑以下情况

...---A---B---C  master
           \
            D---F   feature1 of dev1

接下来，dev1 通过 github 操作提出合并 feature1 到 master 和 github 触发器的“Junit/integration” 测试的拉取请求.

现在，如果我们仔细观察，GitHub 已经在 Commit F 进行了构建和运行测试。

作为 repo 维护者，我预计 GitHub 应该构建并运行对代码进行测试，这将是此拉取请求的结果。
在图表上（参考下面），我希望 GitHub 创建一个 github_tmp 分支，将 master 和 feature1 合并到 github_tmp 和运行测试这个分支。
所以我作为一个 repo 维护者可以非常确定“如果我合并这个拉取请求，我的 master 分支将有好的代码”。
但目前 GitHub 的行为只能证明代码在 commit F 方面表现良好，并不能说明 repo 在合并后仍将保持良好状态。

...---A---B------C  master branch
           \      \  
            \      M github_tmp branch.  <------
             \    / 
              D--F   feature1 of dev1

PS: 一些朋友告诉你应该遵循 rebase feature1 分支的做法，但我认为上述行为应该是默认行为。

我知道我可能遗漏了什么或者没有正确的观点。我怎样才能实现上述行为？

Answer 1

这是预期的行为。

Actions/tests 运行在 PR 上运行在 PR 包含的代码上，而不是最终会合并到主分支中的代码。

其中一个原因是 PR 中的代码甚至可能无法合并到主分支中。

你是对的，使用“rebase”方法可以帮助你实现你的目标。通过确保 PR 始终重新基于主分支之上，您可以保证 PR 的代码与合并后将在主分支中的代码相同。

我相信 GitHub 中有一个设置可以强制 PR 在合并之前重新基于主分支。

在拉取请求期间，Github 在 "feature branch code" 上运行 "Junit" 检查，而不是在 "After merged like code"

During Pull request, Github runs "Junit" checks on "feature branch code" and not on the "After merged like code"

git

github

pull-request

devops