A closing keyword followed by an issue reference closes that issue when the commit or pull request reaches the repository's default branch. The keywords are close, closes, closed, fix, fixes, fixed, resolve, resolves and resolved, in any case and optionally followed by a colon; another repository's issue is written Fixes binarybehemoth/booknest-service-template#1, and each issue needs its own keyword.
Sam's fix for #1 adds title to the allowed sort keys and answers 400 for any other key (Object.hasOwn keeps names such as constructor out), with two new tests; all 13 pass against a local PostgreSQL 1,289 . Until Protection and Merge Queues protects main, it can go straight there:
git commit -q -am "Sort books by title and reject unknown sort keys" -m "Fixes #1"
git push -q
gh issue view 1 --json state,stateReason,closedAt
gh api repos/{owner}/{repo}/issues/1/events \
--jq '.[] | select(.event == "closed") | "closed by commit \(.commit_id[0:7])"'
gh api repos/{owner}/{repo}/issues/6 --jq .sub_issues_summary{"closedAt":"2026-09-25T10:28:45Z","state":"CLOSED","stateReason":"COMPLETED"}
closed by commit 206806f
{"completed":1,"percent_completed":25,"total":4}The issue closed within seconds of the push, the event records the commit, and the parent's progress moved to one of four, as did the milestone's. In a pull request, put the keyword in the description (Closes #2): the issue is then linked under Development while the pull request is open, and closes when it is merged into the default branch. Keywords in pull requests aimed at other branches are ignored, and a mention without a keyword (Refs #3) only cross-links the issue.