1

これは私の保護されたブランチ (マスター) 構成です。

ここに画像の説明を入力

そして、これは私が試したものです:

$ 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'

だから私はgithubmy-repoリポジトリを持っています。コミットをマスターに追加するために必要なbuild-pipelineGitHub アクションを保持しています。必要なチェックステートメントの内容は次のとおりです。

ブランチをこのルールに一致するブランチにマージする前に、どのステータス チェックに合格する必要があるかを選択します。有効にすると、コミットは最初に別のブランチにプッシュする必要があり、ステータス チェックに合格した後、このルールに一致するブランチに直接マージまたはプッシュする必要があります。

だから、ここで私が予想したことが起こります。最後のステートメント^により、ローカルマスターからリモートマスター(保護されている)に直接プッシュできますが、build-pipelineステータスチェックがまだ成功していないため、コミットはリモートで中間状態になります。それがgitの仕組みではないことは承知しています。しかし、保護されていないブランチを作成し、プルリクエストを発行してステータスチェックを実行し、マスターにマージすることを余儀なくされている最後のステートメント^のポイントは何ですか。build-pipeline

4

1 に答える 1