无法理解我的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 '[email protected]:AdityaGovardhan/my-repo.git'

所以我有一个github my-repo 储存库。我有一个 build-pipeline GitHub Action，我将其保留为提交添加到master的必要条件。下面是所需检查声明的内容。

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

所以我预期的情况是这样的。我可以直接从我的本地主站推送到远程主站（它是受保护的），这是因为 最后那句话^但在远程，提交会处于中间状态，因为 build-pipeline 状态检查还没有成功。我知道这不是git的工作方式。但这样一来 最后那句话^ 当它强迫我创建一个非保护分支，并提出一个拉请求来执行 build-pipeline 状态检查，然后合并到主分支。

Answer 1

在GitHub上，状态检查被应用到提交中。 虽然典型的工作流程是打开一个PR，然后以这种方式合并修改，但也可以将你的修改推送到不同的分支，让状态检查在那里运行，然后快速推进你的修改。master 分支到该版本。 提交就已经通过了检查。

请注意，我还没有测试过这个，再说一遍，这不是通常的工作流程，也许你可以试试。 对于那些做rebases和喜欢线性历史的人来说，这将是一个潜在的工作流选项。