Closes #42 only closes: what linking a pull request to an issue actually does

A pull request has been open for three days. Two people have reviewed it. Its description says Closes #42, and issue #42 still says exactly what it said on Monday.

Nothing is broken. The usual way to link a pull request to an issue on GitHub is a closing keyword, and a closing keyword does one thing at one moment. Teams find the gap slowly and go looking for the setting that fixes it. There is no setting. The documentation is worth reading properly once, because it carries three constraints that are rarely stated together, and the third decides whether you need anything beyond GitHub.

What linking a pull request to an issue with a keyword actually does

GitHub supports nine keywords — close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved (docs.github.com). Put one in a pull request description followed by an issue reference and two things happen: the issue shows the pull request as linked, and on merge the issue closes. You can also link by hand, up to ten issues per pull request, from the Development panel in the sidebar.

Constraint one: it only works on the default branch

GitHub states this without ambiguity: "The special keywords in a pull request description are interpreted only when the pull request targets the repository's default branch. If the pull request targets any other branch, then these keywords are ignored, no links are created, and merging the PR has no effect on the issues" (docs.github.com).

Read that again if you run a develop branch, a release branch, or any flow where feature work merges into an integration branch first. Keyword linking there is not degraded, it is inert — no link is created at all, so there is not even a broken one to notice.

Commit messages carry a related trap. Keywords work in them, but "the pull request that contains the commit will not be listed as a linked pull request" — closure without the link (docs.github.com).

Constraint two: nothing reads the branch name

GitHub's mechanism reads a pull request description or a commit message. A branch named fix/closes-42 links nothing to anything; you can attach a branch to an issue by hand from the Development panel, but no keyword does it. That matters because the branch is the first artefact the work produces, days before there is a description to write a keyword in, so any scheme beginning at the pull request is blind to the whole first stretch — which is why where the key sits in a branch name is the load-bearing decision.

Constraint three: there are only two states

The vocabulary gives it away. All nine keywords mean the same thing. There is no GitHub keyword for started, in review or waiting on QA, because the mechanism is bound to the only transition an issue has. In the REST API an issue's state is open or closed, and state_reason records why it closed — completed, reopened, not planned, duplicate (docs.github.com). That is a vocabulary for endings, not for middles.

So keyword linking cannot express the sentence a small team keeps a board for: a human is waiting on another human. People have asked: a community thread requesting that issues move to In Progress when a pull request is attached went unanswered and was marked dormant after sixty days (github.com).

GitHub has conceded half the point itself. In April 2025 it shipped a repository setting that stops merged pull requests closing their linked issues, on the reasoning that for many teams merging code does not mean the work is done (github.blog). Notice the shape of it: a switch to remove the one transition, not a way to add a second.

Three approaches, side by side

The interesting part of Linear's list is not its closing words but the separate non-closing set — ref, part of, relates to and six more — for a pull request that touches an issue without finishing it. By default it moves linked issues to In Progress when pull requests open and Done when they merge (linear.app). That is a better answer than nine synonyms for closed, and worth saying plainly.

Where GitHub keywords are still the right answer

They need nothing: no app, no second account, no integration, no board key for anyone to learn. A drive-by contributor from a fork can write Fixes #91 and it works, because the mechanism lives in the same system as the code — one record, nothing to drift.

If your work merges into the default branch, if closed is the only state you need, and if the people writing pull requests are the people reading the issues, you have your answer, and a tracker will cost more than it returns.

What key-in-branch matching does differently

Kevta takes the third column, and its position is that there is no linking step to forget. Copy a branch name off an issue and you get feature/MS-42-refactor-router. The matcher scans for the board key followed by alphanumerics, anchored on a word boundary and matched case-insensitively, so the key is found wherever it sits and the -slug tail is ignored. The default rule reads the branch head ref, the title, the body and, on a push, the commit messages.

Nothing in that matcher looks at what the pull request targets, which is the practical difference from constraint one: a pull request into develop is matched like one into main. The key scheme is in the boards guide, and which git events are worth binding to a status is a separate question.

Two limits, plainly. If the key appears nowhere, Kevta sees nothing, and there is no Development panel to fall back on: the links on an issue are written by the matcher, not picked by a person. And an outside contributor will not know your board key, which is why open-source repositories stay keyword territory.

Keyword linking is not a weak version of status automation. It is a complete implementation of a smaller thing. If that smaller thing isn't what you needed, Kevta is in beta and we are letting people in from the waitlist.

Disclosure

We build an issue tracker, so the third column of that table is ours. Every claim about GitHub and Linear is quoted from their own docs and linked where made; if any has changed since August 2026, those pages count, not this one.