Docs say a PR from a linked branch is "automatically linked" to the issue, but it is not when the PR targets a non-default branch

Start with the creating-a-branch-for-an-issue article linked in the report and compare its automatic-linking wording with the linked pull request article. Confirm the documented default-branch condition and update the affected passage so it matches the observed behavior. Done when the article clearly explains when automatic linking occurs and the relevant documentation checks pass.

Code of Conduct

• I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-a-branch-for-an-issue

What part(s) of the article would you like to see updated?

The article states, with no condition on the pull request's base branch:

When you create a pull request for a branch that's connected to an issue, it is automatically linked to the issue, and the connection with that branch is removed with only the pull request shown in the "Development" section.

In practice this automatic linking does not happen when the pull request targets a branch other than the repository's default branch. The article should either state that the automatic linking requires the pull request to target the default branch, or the behaviour should be changed to match the current wording.

For comparison, the default-branch requirement is documented for closing keywords on Linking a pull request to an issue ("The pull request must be on the default branch."). There is no equivalent caveat on this page, so readers who create a branch from an issue reasonably expect the link to be created regardless of the base branch.

Additional information

Steps to reproduce (reproduced reliably, on a repository whose default branch is main):

1. Create issue A. From its Development section, use "Create a branch" to create linked branch feature/a.
2. Create issue B. Create linked branch feature/b the same way, based on feature/a.
3. Push a commit to feature/b and open a pull request from feature/b with base feature/a (a stacked pull request).

Expected (per the article): issue B's Development section shows the pull request in place of the branch, and the pull request's closingIssuesReferences contains issue B.

Actual: issue B's Development section still shows the branch, and no pull request appears there. The pull request's closingIssuesReferences is empty, and no connected event is emitted on the issue timeline — only cross-referenced.

Repeating step 3 with base = main behaves exactly as documented: a connected event is emitted about two seconds after the pull request is created, and the branch entry is replaced by the pull request.

Notes

• Manually linking that same pull request to the issue from the Development sidebar does work with a non-default base, and the resulting link is a normal one (closingIssuesReferences becomes populated). So this is not a blanket restriction on non-default base branches — only the automatic linking silently does not run. That asymmetry is what makes the current wording misleading.
• Why this matters: in a stacked pull request workflow every pull request except the first one targets a non-default branch, so each one silently loses its issue link. Nothing in the UI indicates that the link is missing; it is only visible by querying closingIssuesReferences through the API, or by noticing that the Development section still lists a branch rather than a pull request.
• Related, but not the same request: https://github.com/orgs/community/discussions/13240 asks for linked issues to be closed when a pull request merges into a non-default branch. This report is about the link not being created at all, which happens even before any merge.