腾讯云助手规范化Git提交记录

冷门实战｜腾讯云助手规范化 Git 提交记录：改写历史 Commit、生成 Conventional Commits、自动产出 CHANGELOG

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

前言：为什么这篇值得看

网上讲 Git 提交规范的教程不少，但 99% 都是"从新仓库开始"------npm init、装 Husky、配 commitlint、从此人人守规矩。这套流程对新项目 很美好，可一旦遇到跑了三五年的老仓库 ：几十上百条 update、fix、改了一下、tmp 堆积成山，团队想治理却不敢动历史，规范根本推不下去。

这篇博文的方向全网同类内容极少：面向存量老旧仓库，用腾讯云代码助手（CodeBuddy）把历史烂账一笔笔理清，实现三件事：

1. 改写历史 Commit ------把 update 变成 feat(login): 新增短信验证码登录
2. 生成 Conventional Commits------后续提交全部由 AI 基于代码 Diff 自动产出规范信息
3. 自动产出 CHANGELOG------根据规范提交历史，一条命令/一段提示词生成版本变更日志，连带 PR 描述也一并自动化

文末附可直接复制使用的模板提示词，适配团队代码治理场景。

一、场景还原：老旧仓库的三大痛点

先对号入座，你是不是也经历过这些：

痛点 1：历史不可读

$ git log --oneline
c3f2a91 fix
7b8e9d0 update
a1b2c3d 修复
e4f5g6h 改了一下
9a8b7c6 tmp

半年后回来看，除了时间和作者，什么信息都拿不到。git blame 查一行代码为什么这么写，查了个寂寞。

痛点 2：CHANGELOG 无从谈起

CHANGELOG 自动化的前提是提交信息结构化 。fix、update 这种提交，工具根本分不清是"新功能"还是"修 bug"，semver 版本号也跳不准。规范推不下去 → 日志生成不了 → 发版靠人工回忆 → 恶性循环。

痛点 3：PR 描述靠手写，评审靠猜

开发者写完代码懒得写 PR 描述，评审人对着 Diff 猜意图。Code Review 效率低，新人更是无从下手。

核心症结就一个：没有规范化的提交历史，所有依赖提交信息的自动化都是空谈。

二、前置知识：Conventional Commits 规范速览

要治理，先立规矩。约定式提交（Conventional Commits）是目前业界事实标准，格式如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

常见的 type：

type	含义	是否影响版本
feat	新功能	是（minor）
fix	修复 bug	是（patch）
perf	性能优化	是（patch）
refactor	重构（不修 bug 不加功能）	否
docs	仅文档变更	否
style	格式调整（不影响逻辑）	否
test	增加/修改测试	否
chore	构建、依赖等杂项	否
build	构建系统或外部依赖	否
ci	CI 配置变更	否
revert	回滚	否

示例：

feat(auth): 新增短信验证码登录

- 接入腾讯云短信服务
- 增加验证码 60s 重发限制
- 补充登录安全策略

BREAKING CHANGE: 登录接口不再支持纯密码登录

记住这张表，后面所有 AI 生成、历史改写、CHANGELOG 都基于它。

三、实战一：改写历史 Commit（老旧仓库治理的核心）

⚠️ 安全第一 ：改写历史只建议对未推送 或团队明确达成共识的分支执行。已经推送到公共远端、多人基于其开发的历史，改写意味着所有人的本地分支都会冲突，务必走"备份 + 审批 + 强推"流程，见文末风险章节。

3.1 先备份，再动手

# 给当前分支建一个备份，随时能回滚
git branch backup/pre-cleanup-$(date +%Y%m%d)

# 确认备份成功
git branch | grep backup

3.2 小范围试刀：交互式变基改写最近 N 条

# 改写最近 5 条提交
git rebase -i HEAD~5

编辑器会打开这样一个清单：

pick c3f2a91 fix
pick 7b8e9d0 update
pick a1b2c3d 修复
pick e4f5g6h 改了一下
pick 9a8b7c6 tmp

把想改信息的提交前面的 pick 改成 reword（或简写 r）：

reword c3f2a91 fix
reword 7b8e9d0 update
pick a1b2c3d 修复
reword e4f5g6h 改了一下
pick 9a8b7c6 tmp

保存退出后，git 会逐个打开每个提交让修改信息。这里就是 CodeBuddy 的用武之地 ：把这一条提交对应的 git show 输出丢给它，让它重写为规范的 Conventional Commits。

3.3 用 CodeBuddy 重写单条提交信息

先看这条提交改了什么：

git show c3f2a91 --stat
git show c3f2a91   # 看完整 diff

然后把内容交给 CodeBuddy（在 CodeBuddy 对话窗口输入）：

以下是一条 git 提交的全部信息，请根据它的代码 Diff，
用 Conventional Commits 规范重写提交信息。
要求：
1. type + scope 尽量精确
2. description 用中文、动词开头、不超过 50 字
3. 如有破坏性变更，给出 BREAKING CHANGE footer
4. 只输出最终的提交信息，不要解释

<粘贴 git show 的输出>

AI 会输出类似：

refactor(order): 抽取订单状态机，移除重复校验逻辑

- 将订单状态流转收敛到 OrderStateMachine
- 删除 createOrder 中重复的支付状态判断
- 无行为变化，纯结构调整

3.4 大规模批量改写：老仓库整段历史的出路

几十上百条烂 commit 用 rebase -i 一条条改不现实，更高效的做法是批量生成 + 批量应用：

第一步：导出历史提交清单

git log --format='%H %s' --reverse -n 100 > commits.txt

第二步：让 CodeBuddy 批量重写

以下是仓库最近 100 条提交（格式：hash 提交信息）。
请基于提交信息推测每个提交的类型，按 Conventional Commits 规范
输出一张对照表，格式为：

<原hash>|<新提交信息>

规则：
- update/fix/改了一下 这类模糊信息，结合前后文推测类型
- 推测不出的统一标记为 chore
- 保持原 hash 不变，只改提交信息

<粘贴 commits.txt 内容>

第三步：用脚本批量应用 （示例用 git filter-branch，生产环境建议 git-filter-repo）：

# 将 AI 输出的"hash|新提交信息"存为 messages.txt 后
while IFS='|' read -r hash message; do
  git filter-branch -f --msg-filter "sed \"s/^.*$/$message/\"" \
    -- $hash^..$hash 2>/dev/null
done < messages.txt

说明：批量重写是危险操作，生产仓库建议复制一份仓库做演练 ，确认 git log 结果符合预期后再对真实仓库执行。

3.5 改写提交作者/时间的补充技巧

如果还要修正提交者信息（比如入职时邮箱配错了）：

git rebase -i HEAD~10   # 把 pick 改成 edit
git commit --amend --author="Zhang San <zhangsan@example.com>" --no-edit
git rebase --continue

四、实战二：一键生成 Conventional Commits（日常提交）

历史治理完，接下来要保证新提交不再变烂。CodeBuddy 提供了两条路径。

4.1 路径 A：IDE 的 Smart Commit（零配置）

在 VS Code / JetBrains 里装好 CodeBuddy 插件后：

1. 在 Git 面板里暂存改动文件
2. 点击 CodeBuddy 提供的 Smart Commit / AI Commit 按钮
3. 插件会自动分析暂存区的代码 Diff，生成符合 Conventional Commits 规范的结构化提交信息
4. 人工确认后一键提交

它的工作逻辑是：git diff --cached 的差异 → 归纳改动意图 → 映射到 feat/fix/refactor... → 生成 header + body。改动了什么、为什么改动，描述得清清楚楚，还避免了"提交信息与代码不符"的人为失误。

4.2 路径 B：自定义斜杠命令 /commit（团队统一）

CodeBuddy 支持自定义斜杠命令，把"生成规范提交"封装成一个团队统一的命令。在项目根目录创建 .codebuddy/commands/commit.md：

---
description: 基于暂存区 Diff 生成 Conventional Commits 提交信息
argument_hint: 可选的提交说明，如"新增登录页"
---
请根据以下规则，为当前暂存区的代码变更生成一条规范的 git 提交信息：

1. 先运行 `git diff --cached --stat` 和 `git diff --cached` 查看变更
2. 按 Conventional Commits 规范输出，格式：
   <type>(<scope>): <subject>

   <body>

3. type 从 feat/fix/docs/style/refactor/perf/test/chore/build/ci/revert 中选
4. subject 用中文、动词开头、不超过 50 字
5. body 用列表列出关键改动点，控制在 5 条以内
6. 存在破坏性变更时追加 BREAKING CHANGE
7. 只输出提交信息本体，不要输出解释和其他内容

{{ $ARGUMENTS }}

保存后，在 CodeBuddy 输入框敲 /commit 即可复用，团队成员统一口径、强制规范。

4.3 CLI 场景

CodeBuddy Code CLI 同样支持在终端生成符合 Conventional Commits 规范的提交信息并执行提交/推送，适合习惯命令行的同学，操作前它会让你确认生成的信息，避免"AI 擅自提交"的失控感。

五、实战三：根据代码 Diff 自动产出 CHANGELOG

规范的历史有了，CHANGELOG 就是水到渠成的事。两条路线按需选择。

5.1 路线 A：AI 直接生成（零依赖，一次一版）

发版前把两个东西喂给 CodeBuddy：版本间的提交日志 + 关键 Diff。

# 本次版本（比如 v1.2.0 → v1.3.0）的所有提交
git log v1.2.0..v1.3.0 --format='%s'
# 涉及的文件变动概览
git diff v1.2.0..v1.3.0 --stat

模板提示词：

你是一名开源项目维护者，请根据以下 git 提交记录生成 CHANGELOG。

要求：
1. 按"新增 / 修复 / 优化 / 破坏性变更 / 其他"分组
2. 每组用无序列表，条目概括性强、描述清楚
3. 破坏性变更单独突出，标注 BREAKING CHANGE
4. 参考提交信息里的 type 归类：
   feat→新增，fix→修复，perf/refactor→优化，
   BREAKING CHANGE→破坏性变更，其余→其他
5. 输出 Markdown 格式，先给标题行：## [v1.3.0]

<粘贴 git log 和 diff --stat 的输出>

5.2 路线 B：工具链自动生成（一劳永逸，接 CI）

AI 适合"发版时生成一次"，如果想让 CHANGELOG 随每次发布自动产出，用规范化的提交历史 + 工具链更稳。常用组合：

工具	定位	场景
conventional-changelog	根据 Conventional Commits 生成 CHANGELOG	通用，可定制分组
standard-version	自动 bump 版本号 + 生成 CHANGELOG + 打 tag	一键发版
git-cliff	高性能，配置驱动，可自定义模板	大型仓库/自定义格式

以 standard-version 为例：

npm i -D standard-version

# package.json 增加
"scripts": {
  "release": "standard-version",
  "release:major": "standard-version --release-as major"
}

# 发版：自动版本号 + CHANGELOG.md + git tag
npm run release

它会读取 feat/fix/BREAKING CHANGE 自动决定 minor/patch/major，产出类似：

## [1.3.0](https://.../compare/v1.2.0...v1.3.0) (2026-08-28)

### Features
* **auth:** 新增短信验证码登录

### Bug Fixes
* **order:** 修复重复支付校验问题

### BREAKING CHANGES
* 登录接口不再支持纯密码登录

推荐组合 ：日常提交用 CodeBuddy Smart Commit 保规范 → 发版用 standard-version 出 CHANGELOG → 复杂历史/大版本用 AI 人工润色 CHANGELOG。AI 负责"质量和语义"，工具链负责"自动化"。

六、实战四：根据分支 Diff 自动生成 PR / MR 描述

CodeBuddy 的 /mr 斜杠命令可以直接智能创建 Merge Request，让每次代码提交都符合团队规范。它的原理同样是读取当前分支与目标分支的 Diff，归纳出：

• 改动概览（哪些模块、哪些功能）
• 关键改动点（按文件/模块分组）
• 测试影响面与注意事项

一个高质量的 PR 描述模板提示词：

请为以下分支差异生成一份 PR（Pull Request）描述。

分支：feature/login-sms -> main

要求：
1. 标题：一句话概括本次改动（参考 Conventional Commits 的 subject 风格）
2. 正文结构：
   ## 变更内容
   ## 关键实现
   ## 测试情况
   ## 影响范围
3. 变更内容按模块分组，每项一句话说清"做了什么、为什么"
4. 标注可能的破坏性变更与需要重点 review 的文件
5. 语气客观，面向代码评审者

<粘贴 git diff main...feature/login-sms --stat 及关键 diff>

评审效率直接起飞：评审人不用再对着 Diff 猜，PR 描述本身就是一份"代码导读"。

七、模板提示词合集（可直接复制）

场景	提示词要点	输入
生成提交信息	基于暂存区 Diff，type+scope+subject，中文动词开头，≤50 字，body ≤5 条	git diff --cached
改写单条历史	基于 git show 的 Diff 重写为规范格式，保留原意图	git show <hash>
批量改写历史	输出 `hash	新信息` 对照表，供脚本批量应用
生成 CHANGELOG	按 新增/修复/优化/破坏性变更 分组，Markdown 输出	git log + diff --stat
生成 PR 描述	标题 + 变更内容/关键实现/测试/影响范围	git diff main...branch
审查提交合规	检查提交信息是否符合 Conventional Commits 与团队规则	任意提交信息

给团队落地时，建议写进 .codebuddy/rules/ 的团队规则里，让 AI 在每次对话中都自动遵守，比如：

## Git 提交规范（团队强制）
- 所有提交必须符合 Conventional Commits 规范
- subject 使用中文，动词开头，不超过 50 字
- feat/fix 必须写清楚改动原因
- 破坏性变更必须声明 BREAKING CHANGE

八、风险提示与安全边界（老仓库治理必读）

1. 改写已推送历史 = 高危操作 。只治理本地未推送分支；确需重写共享分支，提前通知全组、冻结合并、备份分支、走审批后统一强推（git push --force-with-lease），不要用 --force。
2. 先小规模演练 。用 git clone 复制一份仓库做全流程演练，确认无误再上真实仓库。
3. AI 输出必须人工复核 。AI 生成的提交信息偶尔会夸大/臆测改动意图，提交前逐条过目，尤其是涉及语义版本号的 feat/BREAKING CHANGE 判定。
4. 规范落地靠"流程"而非"自觉" 。历史治理是一锤子买卖，日常防回潮要靠：Smart Commit 习惯 + commitlint 钩子兜底（feat 之外的 type 不允许乱用）+ 人工 review 抽查。

结语

这次实战解决的核心问题是：存量仓库怎么在不动刀动枪的情况下完成提交历史的现代化。

• 历史烂账：rebase -i + CodeBuddy 批量重写 → 一次性理清
• 日常提交：Smart Commit / /commit 斜杠命令 → 持续保规范
• 版本日志：AI 生成 + standard-version 工具链 → 自动化产出
• PR 评审：AI 生成结构化描述 → 评审效率翻倍

CodeBuddy 在这里扮演的角色不是"替代 Git"，而是理解代码的语义层------它读得懂 Diff，才能把"update"翻译成"feat(auth): 新增短信验证码登录"，才能让 CHANGELOG 和 PR 描述真正可读。对团队而言，这是一套"低侵入、高回报"的代码治理方案：不改流程主链路，只把最耗时、最没技术含量又最容易出错的环节交给 AI。

如果你的仓库也是"一年前没人敢动的历史"状态，不妨从 3.1 节开始，先备份，再小范围试几条，你会看到 git log 从"天书"变成"项目史书"的整个过程。