无法显示我的github状态检查操作的操作

Question

这是我的受保护的分支(主)配置：

​

​

这就是我试过的：

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes | 306.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "build-pipeline" is expected.
To github.com:AdityaGovardhan/my-repo.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'git@github.com:AdityaGovardhan/my-repo.git'

所以我有一个github my-repo存储库。我有一个build-pipeline GitHub操作，我根据需要保留了这个操作，以便将commit添加到master。以下是所需的检查语句：

选择必须通过哪些状态检查才能将分支合并到符合此规则的分支中。启用后，提交必须首先推送到另一个分支，然后合并或直接推送到状态检查通过后与此规则匹配的分支。

这就是我所期望的结果。由于最后一条语句^，我可以直接将本地主机推送到远程主机(受保护)，但是由于build-pipeline状态检查尚未成功，提交将处于远程的中间状态。我知道这不是git的工作方式。但是，当最后一条语句^迫使我创建一个不受保护的分支并引发一个拉请求以执行build-pipeline状态检查，然后合并到主服务器时，它的意义是什么？

Answer 1

在GitHub上，状态检查应用于提交。虽然典型的工作流程是以这种方式打开PR并合并更改，但可能会将更改推送到不同的分支，让状态检查在那里运行，然后将您的master分支快速转发到该版本。提交应该已经通过了检查。

请注意，我还没有测试这一点，而且这也不是通常的工作流程，可能是您可以尝试的。对于那些喜欢线性历史的人来说，这将是一个潜在的工作流选项。