这是我的 protected 分支(主)配置:
这就是我尝试过的:
$ 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 '<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="c7a0aeb387a0aeb3afb2a5e9a4a8aa" rel="noreferrer noopener nofollow">[email protected]</a>:AdityaGovardhan/my-repo.git'
所以我有一个 github my-repo
存储库。我有一个 build-pipeline
GitHub Action,我根据需要保留了该操作,以便将提交添加到 master 中。以下是所需检查声明的内容:
Choose which status checks must pass before branches can be merged into a branch that matches this rule. When enabled, commits must first be pushed to another branch, then merged or pushed directly to a branch that matches this rule after status checks have passed.
这就是我预期会发生的情况。由于最后一条语句^,我可以直接从本地主控推送到远程主控( protected ),但提交将在远程处于中间状态,因为 build-pipeline
状态检查尚未成功。我知道 git 不是这样工作的。但是,当它迫使我创建一个不 protected 分支并提出 pull 请求以执行 build-pipeline
状态检查然后 merge 到大师。
最佳答案
在 GitHub 上,状态检查应用于提交。虽然典型的工作流程是以这种方式打开 PR 并 merge 更改,但也可以将更改推送到不同的分支,让状态检查在那里运行,然后快进您的 master
分支到那个版本。提交已经通过了检查。
请注意,我尚未对此进行测试,并且这不是通常的工作流程,您可能可以尝试一下。对于进行 rebase 并喜欢线性历史的人来说,这将是一个潜在的工作流程选项。
关于git - 无法计算我的 github 状态检查操作的操作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62024094/