Introduction

On GitHub, you do not "attach" a pull request to an issue through a separate binding step. The usual workflow is to reference the issue from the pull request title, description, or commits so GitHub creates the relationship and, if you use a closing keyword, closes the issue automatically when the pull request is merged.

The Simple Way: Reference the Issue Number

If the issue is #42, mention that number in the pull request body:

Fixes #42

Other common keywords include:

Closes #42
Resolves #42
Related to #42

These phrases do two different jobs:

• a plain reference such as #42 links the pull request and issue in the UI
• a closing phrase such as Fixes #42 tells GitHub to close the issue when the pull request is merged

If you only want a visible relationship and do not want automatic closure, use a neutral phrase like Related to #42.

Typical Command-Line Workflow

Create a branch, make the change, push it, and open the pull request:

1git checkout -b fix-login-timeout
2git add .
3git commit -m "Handle token refresh during login"
4git push -u origin fix-login-timeout

Then open the pull request on GitHub and include the issue reference in the description:

1## What changed
2- refresh expired tokens before retrying the request
3- add tests for timeout recovery
4
5Fixes #42

Once the pull request is created, the issue page will show that it is linked from an open pull request. After merge, GitHub closes the issue automatically if you used a closing keyword.

Referencing from the Commit Message

GitHub also understands issue references in commit messages. For example:

git commit -m "Fix login timeout handling. Fixes #42"

That can work well for small repositories, but many teams prefer to put the closing keyword in the pull request description instead. The pull request body is easier to edit, easier for reviewers to see, and less likely to be lost in a squash-merge workflow with rewritten commit messages.

Linking Without Auto-Closing

Sometimes a pull request only completes part of the work. In that case, do not use Fixes, Closes, or Resolves. Use a neutral reference:

Part of #42
Related to #42
Refs #42

This preserves traceability without prematurely closing the issue.

That distinction matters in larger projects where one issue may require several pull requests across refactoring, tests, and rollout work.

Cross-Repository References

If the issue lives in another repository, use the full reference format:

Related to octo-org/platform#42

This reliably creates a visible cross-reference. Automatic closure behavior can depend on repository relationship and permissions, so when you are working across repositories, treat the cross-reference as the safe baseline and verify whether auto-closing is appropriate for your setup.

What Reviewers See

When the reference is recognized, GitHub surfaces it in several places:

• the issue timeline shows that a pull request references the issue
• the pull request sidebar may display linked development items
• merging the pull request can close the issue automatically if a closing keyword was used

That shared history is the real value. Reviewers can move from the code change to the original bug report or feature discussion without guesswork.

Good Pull Request Hygiene

Issue linking works best when the pull request description explains the relationship clearly. Do not drop Fixes #42 into an otherwise empty PR body. Add context:

• what changed
• why the change solves the issue
• what was tested

Example:

1## What changed
2- moved retry logic into the API client
3- added an upper bound on token refresh attempts
4
5## Why
6The login flow failed whenever the first request returned an expired token.
7
8## Testing
9- unit tests for refresh behavior
10- manual login verification
11
12Fixes #42

That gives the issue tracker a clean audit trail and gives reviewers enough information to evaluate the patch.

Common Pitfalls

• Mentioning the issue number only in a comment after the pull request is opened. Put the reference in the PR body or commit so GitHub treats it as linked development.
• Using Fixes #42 when the pull request only solves part of the issue. Use a neutral reference if the issue should stay open.
• Forgetting to include the repository name for cross-repo references. Use owner/repo#number when the issue is not in the current repository.
• Relying only on the issue title or branch name to imply linkage. GitHub needs an explicit reference to connect the records.
• Hiding the issue reference inside a noisy or unclear pull request description. Keep the relationship obvious so humans and tooling can both read it correctly.

Summary

• Link a pull request to an issue by referencing the issue number in the PR body or commit.
• Use Fixes #123, Closes #123, or Resolves #123 for automatic closure on merge.
• Use neutral phrases such as Related to #123 when the issue should remain open.
• Cross-repository references should use the full owner/repo#number form.
• A clear PR description makes the issue link useful to both reviewers and future maintainers.