A program manager tracks a checkout bug reported in an issue, now fixed by a pull request from a contractor, and needs traceability for the release notes. Which practice best links pull requests to issues for collaborative tracking?

The correct practice creates a formal, machine-readable relationship between the defect report and the code change by placing a supported closing keyword with the issue number in the pull request body, so merging automatically closes the issue, cross-references both timelines, and preserves an auditable chain from bug to fix for release notes and collaborative review. Referencing the issue number without a closing keyword does establish visibility but fails on automation, leaving the issue open after merge and requiring extra triage that breaks the requested automatic closure workflow. Linking only to a project milestone does support release planning and notes generation but fails on defect-level traceability, because reviewers cannot navigate directly between the checkout symptoms, discussion, and the contractor exact diff. Closing the issue manually after merge does confirm verification but fails on linkage integrity, because the closure event lacks a persistent linked-issue state and depends on human memory and timing, which risks premature or missed closure in a multi-contributor queue. For exams, distinguish plain mentions that merely notify from closing keywords that both link and transition state, and note the keyword must be in the pull request description linked to the correct issue number to score. As a practical check, confirm the pull request sidebar shows the linked issue with pending closure status before merging and that after merge the issue timeline cites the merge commit and the release notes draft includes the change.