关联与自动关闭 Issue 的关键字是什么
在 PR/MR 描述或提交信息里用关闭类关键字加编号，合并到目标分支时平台会自动关闭对应 Issue，省去手工整理。GitHub 支持 close、fix、resolve 的多种形态，GitLab 同样支持关闭模式关键字。要注意生效条件是「目标分支合并时」，写在评论里通常不会触发。若只是想建立引用而不关闭，用 Refs 之类的引用写法更合适。
基本信息
| GitHub 关键字 | close/closes/closed、fix/fixes/fixed、resolve/resolves/resolved 加 #编号 |
|---|---|
| GitLab | 同样支持关闭模式关键字，另可用 !编号 引用 MR |
| 生效时机 | 目标分支合并时关闭；写在 Issue 评论里不会自动关闭 |
| 只引用不关闭 | 用 Refs #编号 等表达 |
| 平台 | GitHub 与 GitLab |
典型使用场景
- 修复缺陷后让 Issue 随合并自动关闭
- 一次改动关联多个相关单号
- 在描述里写明修复了哪些问题，便于评审核对
- 团队统一关联写法，减少人工关闭的操作
- 排查 Issue 未被自动关闭的原因
- 把需求单与实现 PR 建立可追溯的对应关系
常用示例
常用示例
git commit -m 'fix(login): 修复重定向循环' -m 'Closes #4821'
# 描述中的引用写法
# Fixes #4821, resolves #4900
# 只引用不关闭
# Refs #4821关键字与效果
| 写法 | 效果 |
|---|---|
| Closes / Fixes / Resolves #123 | 合并时自动关闭该 Issue |
| Refs #123 | 仅建立引用，不关闭 |
| Fix !45（GitLab） | 引用对应的合并请求 |
同一 Issue 被多个 PR 关联时，先合并的那个触发关闭；引用而非关闭可以用 Refs #编号 表达。
把关闭关键字放在描述或提交页脚都有效，放在提交标题里会让日志冗长，建议统一放在页脚或描述中。
合并到非默认分支时，自动关闭规则可能不生效；需要跨分支关闭 Issue 时先确认目标分支的配置，再决定是否手工关闭。
排查未自动关闭的思路
- 确认关键字拼写与空格格式正确
- 确认编号对应的是 Issue 而不是其他单号
- 确认改动是否真的合并到了预期目标分支
- 确认关键字写在描述或提交信息里，而不是评论中