REST API: GET /repos/{owner}/{repo}/branches/master 301-redirects to the current default branch, in repos that appear never to have had a master

[seekdaseek]

Cross-posted from the documentation issue github/docs#45642, which covers the documentation half. This post is the API behaviour half.

---

This is an API behaviour report, not a security report. I am not describing it
as a vulnerability. The concern is that the behaviour is undocumented and is
contradicted by a published changelog withdrawal, so callers hit it silently.

BEHAVIOUR, measured 2026-08-28 with redirect-following disabled:

symfony/symfony        /branches/master   -> 301 Location=.../branches/8.2
scala/scala            /branches/master   -> 301 Location=.../branches/2.13.x
twitter/finagle        /branches/master   -> 301 Location=.../branches/develop
pytorch/pytorch        /branches/master   -> 301 Location=.../branches/main
kubernetes/kubernetes  /branches/master   -> 200 name=master  (no redirect)
symfony/symfony        /branches/nope-xyz -> 404

BOUNDARY:

• Fires only on the literal name master. trunk, develop and dev all 404
  where absent, including trunk on nodejs/node.
• Fires in repositories created long after main became the default for new
  repositories: anthropics/claude-code (created 2025-02-22) and astral-sh/uv
  (created 2023-10-02) both 301 to main.
• Location tracks the repository's CURRENT default branch in every case
  measured.
• Controls hold: apache/subversion /branches/trunk returns 200 because trunk is
  its default; twitter/finagle /branches/develop returns 200 because it exists;
  a live master returns itself; a never-existing ref 404s.

I make no claim about the cause. Deleted-branch history is not exposed, so
"never had a master" is inference from a creation date, not a measurement.

WHY IT COSTS CALLERS:
Clients that follow redirects by default (urllib, requests, curl -L, most SDKs)
turn the 301 into a transparent 200 describing a branch the caller did not
request. The failure mode is a successful read of the wrong resource: no error,
no warning. Tools that resolve a HISTORICAL branch name are exposed, because a
pull request records its base ref as it was at the time and old PRs name
branches that no longer exist.

In my own use -- comparing a PR's head against the branch that PR targeted --
this silently defeated a fix that existed specifically to avoid comparing
against the default branch. Across 379 pull requests in 108 repositories, 46 of
48 resolution failures were this redirect.

DOCUMENTATION POSITION:

• The REST branches reference lists 301 among the responses without saying when
  it fires or that Location may name a different branch.
• https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/
  announced this redirect, and an update to that same entry dated 2023-02-07
  withdraws it: "This behavior conflicted with other GitHub URL patterns, so we
  removed it. GitHub does redirect renamed branches, but not deleted branches."
  That entry concerns web links, but it currently reads as though the redirect
  no longer exists anywhere.

ASK: either document the behaviour on the branches endpoint, or confirm whether
it is intended to be renamed-branches-only -- the observations above suggest it
is broader. A public docs issue covering the documentation half is filed at
github/docs#45642

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[seekdaseek]

Also filed against the OpenAPI spec repo, which is where the documentation half was routed: github/rest-api-description#7096