GitHub关闭issue的关键词，为何要连同目标分支与消息位置阅读

一条issue旁边出现了拉取请求关联，与issue后来自动关闭，属于协作记录中的不同信息。GitHub官方Linking a pull request to an issue说明，关联使协作者看见有人正在处理问题；当关联PR合入仓库默认分支时，相关issue会自动关闭。[1] 阅读这段规则，还必须保留关键词写在哪里、PR面向哪个分支。

官方特别限定PR描述中的特殊关键词：只有当PR以仓库默认分支为目标时，它们才被解释。如果PR面向其他分支，这些关键词被忽略，不由此创建关联，合并该PR也不会影响issue。这里讨论的是描述关键词这一条路径，不能把它扩大成任何手工关联方式都具有完全相同的条件。

默认分支在这段里因而是规则的适用条件，而非一句可省略的项目背景。假设两份文字说明使用同样的关闭措辞，一份对应默认分支，另一份对应其他分支，文档并没有赋予两者相同效果。这个假设不涉及任何真实仓库，也没有进行合并；它只是说明，摘录关键词时删掉目标分支，会改变原规则的意思。

关键词所在位置还会带来另一项区别。同页说明，提交消息也可以含关闭关键词：当该提交合入默认分支时，issue会关闭，但包含这个提交的PR不会因此被列为关联拉取请求。于是，“issue已经关闭”和“这个PR显示在关联清单中”不能被压缩成同一项事实。

后一条规则对阅读项目交接很具体。若资料只提供issue的关闭状态，尚不足以补出哪一个PR必然出现在关联区域；若提供的是提交消息及其并入默认分支的记录，也应照提交这一层说明，不将它改写为PR描述已经建立关联。文档在这里区分的是记录来源，并未评价改动是否真正修复了业务问题。

官方还区分同仓库、跨仓库以及同时引用多个issue时的表达对象。对资料整理而言，至少要让每个issue保留所属仓库与编号，不能仅凭相同数字将不同仓库的问题并为一条。本文不转写操作语法或修改说明，只将引用对象与前述分支条件放在同一份阅读语境中。

本篇依据GitHub.com当前公开帮助，首次发布日期未确认，没有改变PR、issue、权限或工作流。准确说明一条自动关闭记录，需要同时保留消息位置、目标分支和所引用问题；关联展示则仍按文档自己的规则说明，不能由关闭状态代填。