提交信息为什么值得讲究
提交信息是写给未来的人看的：半年后排查问题时，往往只有它能解释这次改动的原因。约定俗成的结构是主题行、空行、正文，必要时再补页脚。主题行回答「做了什么」，正文回答「为什么这么做」，这个分工能让阅读效率明显提高。
多段信息怎么写
命令行里可以连着写多个 -m，Git 会把它们用空行拼起来，等于手工分段；信息较长或由脚本生成时，用 -F 从文件读取更方便。写信息前用 -v 打开编辑器，还能同时看到 diff 预览，避免边写边回忆改了哪些文件。
基本信息
| 适用平台 | Linux / macOS / Windows（Git 2.x） |
|---|---|
| 结构 | 主题行、空行、正文，可选页脚 |
| 多段写法 | 连续多个 -m 依次拼接为多段 |
| 从文件读取 | git commit -F <文件> |
| 附带预览 | -v 在编辑器里显示 diff |
| 长度建议 | 主题行控制在 50 字符左右 |
典型使用场景
- 说明原因：正文写清为什么这样改，而不只是复述 diff
- 引用缺陷：页脚写关联编号，让平台自动建立关联
- 记录影响：破坏性变更在正文或页脚里写明影响范围
- 脚本生成：用 -F 从文件或模板读取信息，保证格式一致
- 批量统一：用提交模板约束结构，减少漏写上下文
常用示例
常用示例
git commit -m 'fix(api): 处理空响应' -m '在 502 时重试一次，并补回归测试。'
git commit -F msg.txt # 从文件读取信息
git commit -v # 编辑器里附 diff 预览
git log -1 --format=%B # 查看完整提交信息
git commit -m 'fix(api): 处理空响应' -m 'Refs #123'提交信息的结构
| 部分 | 内容 | 写作要点 |
|---|---|---|
| 主题行 | 一句话说明做了什么 | 控制在 50 字符左右 |
| 空行 | 分隔主题与正文 | 不能省略 |
| 正文 | 说明为什么这么做 | 写动机、影响与取舍 |
| 页脚 | 关联编号、破坏性说明 | 便于工具自动解析 |
主题行说明「做了什么」，正文说明「为什么这么做」。把评审者关心的问题写清楚，比逐行复述 diff 有价值得多。
主题行过长会在平台上被截断显示，建议控制在 50 字符左右；需要补充长说明时写进正文，而不是挤在首行。