Fast-forward push rejected with ‘fatal error in commit_refs_rules’

[JustVicki120]

🏷️ Discussion Type

Question

Body

I’m trying to publish a website update. On November 5, GitHub Desktop reached GitHub but rejected a normal push to the main branch with ‘fatal error in commit_refs_rules.’ The pending update adds two files, and the remote branch remains unchanged.

We checked and found no repository rulesets, inherited active rules, or branch protection on main. Rules Insights returned 404, and the rule-suite history API returned 401 with the available access, so we couldn’t inspect the failed push’s evaluation. No repository settings were changed.

GitHub Support closed the ticket without a diagnosis and directed me here. I found a similar discussion, but don’t know if the cause is the same: https://github.com/orgs/community/discussions/212105

What else can we check safely, and can someone help investigate the failed update?

[nikoladimitrov98]

This looks like the same problem as #212105. Since Nov 4–5, several repos on different accounts have had pushes fail at the server's ref-update step with fatal error in commit_refs, and none of them had rulesets or branch protection. The timing matches the Nov 4 Git Operations incident (https://www.githubstatus.com/incidents/smtdswd1h2w4).

The _rules part of your error probably isn't a rule blocking you. When a ruleset really rejects a push, GitHub shows a readable message such as GH013: Repository rule violations found and names the rule. A bare "fatal error" from a server step points at GitHub's side.

Safe checks (read-only or easy to undo):

1. See which rules GitHub applies to main, including org-level ones. This only needs read access:

gh api repos/OWNER/REPO/rules/branches/main

If it returns [], no rules apply. Rules Insights and the rule-suites API usually need admin access, which
likely explains your 404 and 401.

2. Confirm the remote is unchanged and your push is still a fast-forward:

git fetch origin
git status

You should see "ahead of 'origin/main' by 1 commit". If it says "diverged", something else is going on.

3. Back up the unpublished commit before trying anything else. Copy the folder, or run:

git bundle create ../site-backup.bundle --all

4. Retry once from the command line and capture a request ID (HTTPS remote):
GIT_TRACE_CURL=1 git push origin main 2>&1 | grep -i "x-github-request-id"
Note the time in UTC. Git hides your token in this output by default, but only share the request-ID line.

5. Check whether the whole repo is affected or just main:

git push origin main:refs/heads/push-test

If this fails with the same error, ref updates are broken for the whole repo, as in #212105. If it succeeds, the problem is specific to main. You can delete the test branch later.

Avoid: force-pushing, deleting or renaming main, deleting and recreating the repo, or rewriting history. None of these fixes a server-side ref failure, and they can make data loss or a staff investigation harder.

What has worked so far: two reporters in #212105 and #212116 say the problem cleared later with no change on their side. Retry the normal push from time to time.

If the website update can't wait: in the control test in #212105, a newly created repository accepted the same push. As a temporary measure you could push to a new repo and point your site at it, then switch back once the original repo works again.

Getting it investigated: Support has been closing these tickets as self-service. Your best route is a comment on #212105 with:

• the repository ID (gh api repos/OWNER/REPO --jq .id)
• the UTC time of the failed push
• the request ID
• the exact error text

Staff can trace request IDs, and one thread with many reports is more likely to get picked up. If the account or org is on a paid plan, reopen the ticket and cite the request ID and #212105.