skip to content

Issues and Projects

17 roadmaps6 questions

Tracking the work next to the code: issue templates and labels, milestones, and Projects boards with custom fields and automation that move cards as PRs progress. Interviewers ask because linking an issue to the PR that closes it is the thread that makes history readable months later.

part ofGitHuboverview, primer and where to startread it →
on this pageshow

explore

questions

6

In GitHub, how do you make a merged pull request close an issue automatically?

level: juniorimportance: must knowfreq 72%

answer

  1. Two objects, one link on merge
  2. Certain verbs before the number matter
  3. Description or commit, not a comment
  4. Only the repository's default branch

basics

~20 s

Put a closing keyword and the issue number, such as "Fixes #123", in the pull request description or in a commit message. When that pull request merges into the repository's default branch, GitHub closes the linked issue.

solid answer

~40 s

GitHub recognises nine closing keywords — `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`, `resolve`, `resolves`, `resolved` — followed by an issue reference such as `#123`. Put one in the **pull request description** or in a **commit message**; a plain comment on the PR does not create the link. The issue is not closed when the PR opens — GitHub shows it in the PR's *Development* section as "linked", and closes it only when the PR is **merged into the repository's default branch**. Merging the same PR into `release/1.4` links the issue but leaves it open. Cross-repository works too: `Fixes octo-org/api-service#123`, provided you have write access to the target repo. You can also link manually from the PR sidebar's *Development* panel, which behaves the same way on merge.

code

text · 8 lines
text
Handle expired refresh tokens on the /session endpoint

Rejects a refresh token whose family was revoked and returns 401
instead of a 500.

Fixes #482
Closes octo-org/api-docs#77
Related to #451

go deeper

for a junior

Memorise the shape: a closing keyword such as Fixes plus #123 in the pull request description, and the issue closes when the pull request merges. Be ready to say where the keyword must go.

for a middle

Explain the mechanics: which keywords are recognised, that the description and commit messages count but comments do not, and that the close fires only on merge into the default branch.

for a senior

Show you have debugged the failure mode — issues left open because work merges into an integration or release branch first — and describe how your team closes the loop instead, for example from the release pull request.

for a principal

Own the argument for why the issue-to-pull-request thread is worth enforcing at all: it is the cheapest durable record of intent, and it decays fast unless linking is a habit rather than a checklist item.

## What the mechanism is A GitHub issue and a GitHub pull request are separate objects, but GitHub keeps a first-class *link* between them so that closing the work item is a side effect of merging the code rather than a second manual chore. That link is created by writing a **closing keyword** followed by an issue reference. ## The keywords GitHub accepts these, case-insensitively: `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`, `resolve`, `resolves`, `resolved`. Each must be immediately followed by an issue reference — `#123` for the same repository, or `owner/repo#123` for another one, or a full issue URL. `Fixes #123` links. `Fixed in #123`, `Related to #123`, or a bare `#123` do **not** link; they render as a cross-reference only, which is exactly what you want when a PR touches an issue without finishing it. ## Where the keyword has to live Two places count: the **pull request description** (the body of the PR itself) and **commit messages** on the branch. A keyword typed into a PR *comment*, a review comment, or an issue comment does not create a closing link. This trips people up constantly — they add "fixes #123" as a comment after opening the PR and are surprised the issue stays open. Editing the PR description after the fact does work; the link is re-evaluated. A keyword in a commit message closes the issue when that commit lands on the default branch, which can happen through a direct push as well as through a merge. ## The default-branch rule GitHub closes linked issues only when the pull request merges into the repository's **default branch** (usually `main`). This is the single most-missed detail. If your process merges feature work into `develop` first, or if you cherry-pick a fix onto `release/1.4`, the issue is linked but stays open until something reaches the default branch. Teams that keep a long-lived integration branch usually accept this and close issues from the release PR instead. Equally, closing the PR without merging it does not close the issue — GitHub unlinks nothing but performs no close. ## The Development sidebar Every pull request has a *Development* section in its right-hand sidebar. Picking an issue there creates the same link without touching the description, and the issue closes on merge in the same way. The reverse direction exists too: from an issue you can create a branch, which pre-links whatever PR is opened from it. Once linked, the issue shows a timeline entry naming the PR, and the PR shows the issue — this is the thread that makes the history readable months later, when someone asks *why* a line changed and the blame leads to a PR that leads to an issue with the discussion. ## Cross-repository links `Fixes octo-org/api-service#123` closes an issue in a different repository, provided the account merging has write access to that repository. This matters when the code lives in a service repo but the work is tracked in a central planning repo. ## What it does not do Closing keywords are a **GitHub** feature, not a Git one. Nothing in the commit object, in `git log`, or in a mirror on another host reacts to the word `fixes`. They also do not manage state beyond closing: the issue's project status, its milestone, and its labels are untouched unless something else (a project workflow) reacts to the close event. ## Why interviewers ask It is a cheap probe for whether a candidate has actually shipped through a review process. Someone who has will know the default-branch rule and the comment-vs-description distinction, because both have bitten them.

  • The pull request merged into release/1.4 and the linked issue is still open — why?
    GitHub closes linked issues only when the pull request merges into the repository's default branch. Merging into `release/1.4` keeps the link visible in the *Development* section but performs no close. Either close the issue from the pull request that brings the release branch back to the default branch, or close it by hand and note the release it shipped in.
  • How do you reference an issue from a pull request without closing it on merge?
    Drop the keyword. A bare `#123`, or wording like `Related to #123`, creates a visible cross-reference in both timelines but no closing link. Use it when a change is partial progress on a larger issue, or when the issue tracks something broader that only a human should decide is finished.
  • Can a pull request close an issue in a different repository?
    Yes — use the fully qualified form `owner/repo#123` or the issue's full URL in the pull request description. The account merging the pull request needs write access to the repository that owns the issue; without it the reference renders as a plain cross-link and nothing closes.

saying these in an interview costs you the question

  • Thinks any mention of #123 in a PR closes the issue
  • Says the keyword works from a pull request comment
  • Assumes merging into any branch closes the issue
  • Believes closing keywords are Git behaviour, not GitHub's
  • Expects the issue to close when the PR opens

context

resolving links…

open as a page

In GitHub Projects, what do custom fields and views add on top of issue labels?

level: middleimportance: should knowfreq 45%

basics

~20 s

A GitHub Project stores extra data per item — status, priority, estimate, iteration, target date — as typed fields that labels cannot express, and renders the same items as a table, a board, or a roadmap with independent filters, grouping and sorting per view.

open as a page

In GitHub, what does a YAML issue form give you that a Markdown issue template does not?

level: middleimportance: should knowfreq 52%

basics

~20 s

A GitHub issue form renders real input widgets — required text boxes, dropdowns and checkboxes — so the reporter cannot submit an empty or half-filled report. A Markdown template only pre-fills editable text that anyone can delete.

open as a page

In GitHub Issues, when is a milestone the right tool instead of a label?

level: middleimportance: should knowfreq 38%

basics

~20 s

Use a GitHub milestone when the question is "is this batch of work done yet" — it holds one due date and shows a completion percentage. Use labels for everything an issue can be several of at once, like type or component.

open as a page

How would you keep a GitHub Projects board updated as PRs move, without dragging cards?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Lean on the project's built-in workflows first — auto-add items by filter, then set Status when an item is added, a review is requested or approved, a pull request merges, or an item closes. Reach for an Action or the GraphQL API only for what those cannot express.

open as a page

Across 200 GitHub repos in one org, how do you keep issue triage consistent?

level: principalimportance: nice to knowfreq 24%

basics

~20 s

Accept that GitHub labels, milestones and templates are repository-scoped, then centralise what it offers: default issue templates in the org's .github repository, organisation-level Projects that span repos, and a scripted label taxonomy applied through the API.

open as a page