Pull Request Lifecycle

## What the keyword is for GitHub keeps issues and pull requests in the same numbering space, and a bare `#142` anywhere in a description or comment renders as a cross-reference link. A *closing keyword* does more than link: it declares intent, so that merging the pull request also finishes the issue. That single mechanism removes the most common source of stale trackers — work that shipped but whose issue nobody closed. ## The exact rules - **Keywords.** `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`, `resolve`, `resolves`, `resolved`. Case does not matter. Words such as *completes*, *addresses* or *implements* are ordinary prose to GitHub and create no link. - **Where they must appear.** In the pull request's description, or in a commit message that the pull request contains. A keyword in a follow-up comment or in the pull request title does not create the closing link. - **When the issue closes.** Only when the pull request is merged into the repository's **default branch**. Merging a keyword-bearing pull request into a release branch links the two but leaves the issue open; the issue closes later, when the change reaches the default branch through some other pull request that also carries the keyword. - **One keyword per issue.** `Closes #1, #2` closes only issue 1 and merely references issue 2. Write `Closes #1, closes #2`. - **Cross-repository.** Use `owner/repo#142`. You need permission on the target repository for the close to take effect. ## What it looks like in the interface A linked pull request appears in the issue's *Development* sidebar and the issue appears in the pull request's. The pull request's merge event carries the closure, so the issue's timeline reads "closed via #987", which is the audit trail people actually rely on months later when asking "where did this change come from". ## Why interviewers ask it It is a two-minute question that separates people who have run a real pull request workflow from people who have only pushed branches. The details that trip candidates up are the default-branch condition and the one-keyword-per-issue rule; both cause visible confusion on real teams ("the issue didn't close, the automation is broken") and both have simple explanations. ## Related behaviours worth knowing - **Manual linking.** You can attach an issue to a pull request from the *Development* panel without a keyword, which is useful when the issue lives in a repository whose text you do not want to edit or when the pull request only partially addresses it. - **Reverting.** If the change is later reverted through a revert pull request, the issue does **not** reopen automatically. Reopening is a human decision and someone has to make it. - **Closing the pull request without merging.** Closing a pull request unmerged never closes its linked issues; only a merge into the default branch does. - **Branch-based linking.** Creating a branch from an issue also establishes a link, so the eventual pull request shows the connection without anyone typing a keyword. ## How to phrase a strong answer Start with the effect ("it links the two and auto-closes the issue on merge to the default branch"), then add the constraint that matters ("description or commit message, not a comment, and one keyword per issue"), then the cross-repository form. Mentioning that a revert does not reopen the issue shows you have watched this play out during an incident, which is exactly the extra sentence that turns a correct answer into a convincing one.