会话解决是什么
评审中的行内评论会形成一条条讨论线程（GitHub 叫 conversation，GitLab 叫 discussion）。每条线程处理完之后可以标记为已解决（Resolve）。仓库可以开启「合并前必须解决全部会话」的强制项：只要还有未解决的线程，合并就会被拦住，避免意见没处理就悄悄合入。
基本信息
| GitHub 操作 | Resolve conversation |
|---|---|
| GitHub 强制项 | Require conversation resolution before merging |
| GitLab 操作 | Resolve discussion |
| GitLab 强制项 | 要求所有讨论解决后才能合并 |
| 作用 | 把处理结论沉淀到讨论记录里 |
典型使用场景
- 逐条回复评审意见后关闭对应会话，让评审形成闭环
- 不接受某条建议时也写明理由再解决，保留取舍依据
- 合并前核对是否还有未解决线程，避免漏改遗留问题
- 交接或事后追溯时，用已解决会话还原当时的决策过程
- 对同一处代码反复讨论时，用解决状态标记这一轮是否收口
核对与查看
核对与查看
gh pr view 128 --json reviewDecision,comments # 查看评审结论与会话内容
gh pr checkout 128 # 检出 PR 分支做本地核对
git log --oneline origin/main..HEAD # 确认改动提交是否齐全
git diff origin/main...HEAD -- <文件> # 只看被评论的那处改动会话状态对照
| 状态 | 含义 | 对合并的影响 |
|---|---|---|
| 未解决 | 意见尚未处理或尚未回复 | 开启强制项时阻止合并 |
| 已解决 | 已处理或已给出明确结论 | 不阻止合并 |
| 已过期 | 被评论的代码行在后续提交中已改动 | 需人工确认是否仍需处理 |
对不接受的意见也要回复并关闭会话，把结论留在讨论里，便于后来人理解取舍。只点解决却不写原因，讨论记录会失真，看起来像把意见压下去了。
要求全部会话必须解决，适合公共库或安全敏感仓库；人数少的团队容易把它变成负担，也可以只在高风险目录对应的 PR 上启用。
开启这项要求之后，讨论数量会明显上升：把可以合并的同类意见写成一条评论，比逐行重复同一条建议更省事，会话也更容易收口。