GitHub・プルリク・ブランチの保護・2026年10月30日に確認

GitHub：「GH006: Protected branch update failed」と「GH013: Repository rule violations found」

ブランチを守るルールに合わない push は GitHub に断られ、Git は remote: で始まる行にその答えを出します。ブランチ保護なら最初の行が GH006 で、次の行に理由が出ます（GitHub の説明「About protected branches」・2026年10月30日に確認）。ルールセットなら GH013 で、「GH013: Repository rule violations found for refs/heads/main」のように出ます（GitHub の説明「Troubleshooting your migration with GitHub Enterprise Importer」）。

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

直接の push を断るルール

Require a pull request before merging（ルールセット）：そのブランチへの変更は、すべてプルリクに結びついていなければなりません。プルリクは承認されていなくてもよく、開かれていれば足ります（GitHub の説明「Available rules for rulesets」）。REST API ではルール pull_request です。「Changes must be made through a pull request.」という文は、GitHub の MCP サーバーの試験に API のエラーとして載っています（github/github-mcp-server）。
Require a pull request before merging（ブランチ保護）：ブランチ保護のルールの「Protect matching branches」の下にあります。承認を求める設定なら、共同作業者が保護されたブランチへ変更を入れられるのは、書き込みの権限がある決まった数のレビュアーが承認したプルリクを通したときだけです（GitHub の説明「Managing a branch protection rule」・「About protected branches」）。
Restrict updates・Restrict who can push：ルールセットの Restrict updates（update）は、迂回の権限がある人だけが当てはまるブランチへ push できるようにします。ブランチ保護の Restrict who can push to matching branches は、許された人・チーム・アプリだけが push できるようにし、その人たちもプルリクが必須ならプルリクを作る必要があります。
必須のチェック：必須のチェックが合格する前に保護されたブランチへ push すると、GH006 で断られます（必須のチェックが「Expected」のままを参照）。
手元で作ったマージコミット：Dismiss stale pull request approvals when new commits are pushed か Require approval of the most recent reviewable push が入っていると、プルリクのマージコミットを手で作って保護されたブランチへ直接 push しても失敗します。中身が GitHub がそのプルリクで作るマージとまったく同じときだけ通ります。

それでも push できる人

管理者（ブランチ保護）：既定では、ブランチ保護のルールの制限は、リポジトリの admin の権限を持つ人と、「bypass branch protections」の権限を持つカスタムロールには効きません。Do not allow bypassing the above settings を入れると、その人たちにも効きます。
選んだ人（ブランチ保護）：Allow specified actors to bypass required pull requests で選んだ人は、プルリクを作らずにブランチへ push できます。
迂回のリスト（ルールセット）：リポジトリの admin・組織と Enterprise のオーナー・maintain か write のロール・チーム・GitHub Apps・Dependabot に迂回を許せます。For pull requests only（REST API では bypass_mode: pull_request）にした人は、変更するにはプルリクを開く必要があり、そのうえでブランチの保護を迂回してマージできます。迂回のリストに入っていても、直接 push できるとは限りません（GitHub の説明「Creating rulesets for a repository」・「REST API endpoints for rules」）。

直し方

コミットを新しいブランチに移してプルリクを開く：push を断られたブランチの上で、同じコミットに新しいブランチを作り、そちらを push します。
```
git switch -c fix-login
git push -u origin fix-login
```
そのあと、保護されたブランチを base、新しいブランチを compare にしてプルリクを開きます。リポジトリのページでブランチを選び、ファイルの一覧の上の Compare & pull request を押します（GitHub の説明「Creating a pull request」）。手元の main は断られたコミットを指したままで、GitHub の main にそれが入るのはプルリクがマージされたときです。
どのルールかを見る：Rulesets のページでは、読む権限がある人なら誰でも、そのブランチに効いているルールセットを見られます。リポジトリの設定の Rules → Insights には、ルールセットに照らした操作が、通った・断られた・迂回された、の別で出ます（GitHub の説明「Managing rulesets for a repository」）。REST の Get rules for a branch は、リポジトリと組織のどちらで決めたルールも、そのブランチ名に効くものを全部返します。まだ無いブランチの名前でも返ります（GitHub の説明「REST API endpoints for rules」）。
手元でなく GitHub でマージする：自分で作ったマージコミットを push する代わりに、GitHub でプルリクをマージします。
どうしても直接 push する必要があるとき：管理者に、Allow specified actors to bypass required pull requests か、ルールセットの迂回のリスト（Always allow）に入れてもらいます。

IntelliJ IDEA は「rejected by the remote」とだけ言い、GitHub の理由は出さない

IntelliJ IDEA に入っている Git と GitHub の機能が、GitHub に断られた push をどう扱うか。ソース（2026年11月1日に確認・IntelliJ IDEA：GitPushOperation.java・GitPushNativeResultParser.java・GitPushNativeResult.java・GitPushRepoResult.java・GitPushResultNotification.java・GitBundle.properties・VcsNotifier.java・GitPusher.kt・GHPushNotificationCustomizer.kt・GHPRCreatePullRequestAction.kt・GithubBundle.properties）では：

断られたブランチ：IDE は push への Git の答えを、ブランチごとに1行（印と、かっこの中の理由）で読みます。印が ! のブランチは、理由が non-fast-forward・fetch first・failed to lock・stale info のどれでもなければ、リモートに断られた物として扱います。リポジトリが1つのプロジェクトでは、通知の題は「Push rejected」（push が断られた）になり、本文はブランチの名前だけで組み立てられます（例：「Push main to origin/main was rejected by the remote」＝main から origin/main への push はリモートに断られた）。Git が示した理由は結果と一緒に取っておかれますが本文には使われないので、GH006 や GH013 の行は本文に入りません。
ブランチごとの答えが無いとき：Git の出力にどのブランチの行も無ければ、push は失敗として扱われ、通知の題は（リポジトリが1つなら）「Push failed」（push に失敗した）、本文は Git のエラー出力になります。どちらの場合も、VCS のコンソールが空でなければ、通知に「Show details in console」（詳しくはコンソールで）も付き、押すとコンソールのタブを開いて最後までスクロールします。
断られた時はプルリクを勧めない：push の後、GitHub の機能が通知に操作を足すのは、push に成功したブランチで、IDE にアカウントのある GitHub のリポジトリのもので、そのリポジトリの GitHub での既定のブランチでない時だけです。そのブランチからの開いたプルリクが無ければ「Create pull request」（プルリクを作る）、ちょうど1つあれば「View pull request」（プルリクを見る）です。断られたブランチにはどちらも付きません。
コミットを新しいブランチに移した後：そのブランチを push すれば、通知に「Create pull request」が付くことがあり、押すと IDE の新しいプルリクの作成に進みます。そこでマージ先のブランチをどう選び、push するかをどう決めるかは GitHub：ブランチが見つからなかった理由の節に、Push の画面がどのブランチへの強制 push を止めるかは GitHub：強制 push が止められるの節にあります。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の横に出します。プラグインは push しません。新しいブランチに移ったら、チェックアウトしているブランチから保護されたブランチへのプルリクを作り、マージ先は打つそばから GitHub にあるリポジトリのブランチを出します。ブランチがまだ GitHub に無いときは、そう言って IDE の push のダイアログを開きます。そのあとのマージは、マージ先のブランチが許す方法で GitHub で行います。受信箱・差分・会話は無料、プルリクの作成・承認・コメント・マージは Pro（月 US$1.50・30日の試用つき）です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc. や JetBrains とは関係がなく、承認も受けていません。