主要观点：

• 在 GitHub 的 curl 项目中，拉取请求提交后通常显示为“已关闭”而非“已合并”，此情况自 2015 年起存在且短期内不会改变。
• 原因在于 GitHub 的 UI 不允许对拉取请求的提交消息进行审核和评论，导致提交消息易出错且未及时更新。
• 为确保提交消息正确，项目团队手动合并拉取请求，通过特定指令让 GitHub 关闭相关问题或拉取请求。
• 虽理论上可在本地手动清理并推送提交以让其在 GitHub 显示为“已合并”，但这繁琐且耗时，不值得。
• GitHub 可提供“已合并”关键字，以更好地帮助用户和贡献者理解关闭的拉取请求已被合并。

关键信息：

• 展示了 GitHub 中关于拉取请求合并的相关截图。
• 强调了良好的提交消息格式对项目的帮助，以及 curl 项目中喜欢并使用严格的线性历史。
• 说明了手动合并拉取请求的过程和相关指令的作用。

重要细节：

• 提交消息基于单个提交时，初始 PR 消息基于提交消息，但后续更新时未相应更新。
• “Fixes #[number]”指令用于关闭与该编号对应的 GitHub 问题，“Closes #[number]”用于关闭对应编号的拉取请求。
• 手动合并拉取请求需将其拉到本地仓库清理消息后再推送，推送的提交消息中可能包含上述指令。
• 若 GitHub 允许，作者希望禁用 GitHub PR UI 中的合并按钮，因为在项目中无法正确使用。
• 合并拉取请求时不 squash 所有提交，以保留每个提交的独立性和正确消息。
• 文末说明手动合并提交方式不影响作者的贡献记录和信用，GitHub 会正确统计提交者的提交次数。