Fixes #1234: The first line of the PR description, the keyword to close issues

Today's English Expression 7/30 · Stage: PR Description. All example sentences are created for this post. They are not taken from PRs in actual repositories, and the issue numbers are examples.

Table of Contents

• At a Glance
• 1. Meaning and Nuance
• 2. Examples
• 3. Similar Expressions and Differences
• 4. Common Mistakes Made by Korean Speakers
• 5. One-Line Practice
• Model Answer
• References

At a Glance

1. Meaning and Nuance

According to GitHub documentation, if you use a closing keyword and an issue number together in a PR description or commit message, the PR and issue are linked, and the issue is automatically closed when the PR is merged. There are nine keywords: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. The documentation explains that you can also write them in uppercase or append a colon after the keyword (CLOSES #10, Closes: #10).

There is one important condition. The keyword works only when the PR targets the repository's default branch (usually main). Even if you use Fixes in a PR targeting a release branch, the issue will not be closed and no link will be created. When referring to an issue in another repository, append the repository name like Fixes owner/repo#1234. If there are multiple issues, you must attach a keyword to each issue , such as Fixes #10, fixes #11.

The PR template in Kubernetes has a field named Which issue(s) this PR is related to, and the guide instructs you to prepend Fixes to the issue number. The KubeVirt PR template also places a Fixes # line in the References section and guides you to write it in this format if you want the issue to be closed upon merging.

Keep in mind the nuance as an English sentence as well. fixes means "fixes a bug", closes means "ends an issue" (natural for feature requests or documentation work as well), and resolves is somewhere in between. While the functionality is identical, choosing the word that fits the nature of the issue makes it easier to read.

2. Examples

Scenario 1: First line of a bug fix PR

Fixes #1234

The restore job now waits for the PVC to be bound before starting the pod.

Place the keyword on the first line, followed by a blank line and one or two sentences describing what was changed.

Scenario 2: Linking an issue without closing it

Part of #2001. This PR adds the API field only; the controller logic will follow in a separate PR.

If it is part of a larger task, you should not use Fixes. This is because the moment this PR is merged, the unfinished issue would be closed. Words like Part of, Related to, and Refs are not keywords, so they do not close issues.

Scenario 3: When a reviewer requests a link

Could you add Fixes #1234 to the PR description so the issue gets closed on merge?

3. Similar Expressions and Differences

• Closes #1234. More natural for non-bug issues such as feature requests or documentation tasks. The behavior is identical.
• Related to #1234 / Refs #1234. Links only and does not close. GitHub turns the number into a link and leaves a mention record on the issue side.
• Follow-up to #1200. Means it is follow-up work for a previous PR. It connects to 10 follow-up PRs.

4. Common Mistakes Made by Korean Speakers

• This PR is for fixing the issue #1234. The sentence makes sense, but because it is not in keyword format, the issue may not be closed. Also, do not use articles like the issue #1234.
  • Corrected sentence: Fixes #1234
• Fix #1234 issue. It looks like an imperative sentence and appending issue at the end sounds awkward.
  • Corrected sentence: Fixes #1234
• Fixes #10, #11 The second issue lacks a keyword, so it will not be closed.
  • Corrected sentence: Fixes #10, fixes #11

5. One-Line Practice

Write the following content as the first two lines of a PR description. This PR only partially resolves issue 3456.

It is part of issue 3456. This PR only fixes the documentation.

Model Answer

Part of #3456

This PR only updates the docs. The code change will follow in a separate PR.

Since it only partially resolves the issue, use Part of instead of Fixes. will follow means "will come next".

Titi's Tip. Fixes is a keyword that GitHub reads and acts upon. Use it only when the issue is fully resolved.

References

• GitHub Docs, Linking a pull request to an issue: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue
• Kubernetes PR template: https://github.com/kubernetes/kubernetes/blob/master/.github/PULL_REQUEST_TEMPLATE.md
• KubeVirt PR template: https://github.com/kubevirt/kubevirt/blob/main/.github/PULL_REQUEST_TEMPLATE.md