回退提交怎么写
回退提交也应遵守提交信息规范：约定用 revert: 前缀，标题引用被回退提交的标题，正文写明回退原因与影响范围，并附上被回退提交的哈希。自动生成的 Revert '...' 信息可以直接用，但按团队规范改写之后，历史更容易被检索和理解。
基本信息
| 约定前缀 | revert: <被回退提交的标题> |
|---|---|
| 正文内容 | 说明回退原因与影响范围 |
| 引用对象 | 正文中附被回退提交的哈希 |
| 工具行为 | 自动生成的信息可直接使用，也可改写 |
典型使用场景
- 回退线上出问题的改动，并在信息里说清原因
- 规范化的回退记录便于按前缀检索全部回退动作
- 公开发布的回退提交中给出被回退对象，方便依赖方判断影响
- 回退之后又重新修复提交时，在信息里注明两者关联
- 按提交类型统计时，把回退动作单独归类
常用示例
常用示例
git revert --no-edit <哈希> # 使用自动生成的提交信息
git log -1 --format=%B # 查看完整提交信息
git revert --no-commit <哈希> # 只落改动，便于人工整理信息
git commit -m 'revert: 回退登录改版（引发重定向循环）' # 按规范改写信息
git log --oneline --grep='^revert:' # 检索全部回退类提交信息要素
| 要素 | 内容 | 作用 |
|---|---|---|
| 前缀 | revert: | 便于按类型检索与统计 |
| 标题 | 被回退提交的标题 | 一眼看出回退了什么 |
| 正文 | 回退原因与影响范围 | 判断是否需要重新实现 |
| 引用 | 被回退提交的哈希 | 精确指向被回退的对象 |
回退同样要写清楚原因，方便后人判断是被回退的改动本身有问题，还是需要调整设计后重新提交。
多个提交连续回退时逐个回退并写明原因更清晰；压成一次大回退会丢掉提交之间的对应关系。
回退之后紧接着会有人问「还改不改」：在信息里写清是暂时规避还是彻底放弃，能省下一轮沟通，也便于日后决定是否重新实现。