A technical project manager tracks a checkout bug in issue #214 while two developers open separate pull requests with fixes and need traceability for release notes and automatic status updates. The team uses GitHub Issues and pull requests with closing keywords. How should the team link pull requests to issues for accurate collaboration?
Select an answer to reveal the explanation.
Short Explanation
You can keep both fixes tied to the bug and make release-note tracking clearer. Closing keywords in each pull request description link the work to the issue and update its status when merged.
Full Explanation
Adding Fixes #214 in each pull request description works because GitHub parses closing keywords in the pull request body to create a link between each pull request and the issue, show the linked pull requests on the issue timeline, and auto-close the issue when a fix is merged to the default branch. This gives the team traceability for release notes and keeps issue status in step with the work. Adding #214 only as a Project board card note may help visually group the work, but it does not create the issue timeline link or trigger automatic closure. Putting the issue number only in a force-pushed commit author name does not establish issue linkage: author metadata identifies contributors, and rewriting history can obscure review context. Copying the issue text into wiki pages may make documentation searchable, but it does not provide live state synchronization between the pull requests and issue. Exam caveat: closing keywords must appear in the pull request description or in a commit message on the default branch for automatic closure. Practical check: open the issue timeline and confirm both pull requests appear as linked before merging.