真正可用的 changelog 生成路径是 standard-version 配合 conventional commits：需提交严格遵循 feat(api): add timeout option 格式，运行 npx standard-version --release-as 1.4.0 自动生 CHANGELOG.md、打 tag、更新版本。
git log 生成 changelog 的核心命令
直接用 git log 能出日志，但默认格式不适合当 changelog：没有语义化分组、缺少版本锚点、提交信息杂乱。真正可用的起点是带格式化和范围限制的命令。
- 按版本区间提取（比如从 v1.2.0 到 v1.3.0）：
git log v1.2.0..v1.3.0 --pretty=format:"* %s (%an)" --reverse - 过滤掉合并提交（避免日志里全是 “Merge branch…”）：
--no-merges必加 - 只取 feat/fix/docs 类型的提交（需团队约定前缀）：
git log --grep="^feat\|^fix\|^docs" -i
conventional-commits + standard-version 是最稳的自动化路径
手动拼 git log 命令容易漏版本、难维护、不兼容 CI。用 standard-version 配合 conventional commits 约定，才能真正“自动生成”——它不是魔法，而是靠规则换确定性。
- 前提：所有提交必须遵守
feat(api): add timeout option这类格式，否则standard-version无法分类 - 安装后运行：
npx standard-version --release-as 1.4.0，它会自动：生成CHANGELOG.md、打 tag、更新package.json版本 - CI 中慎用
--skip.tag：跳过打 tag 看似安全，但后续git log v1.3.0..v1.4.0就会失效
GitHub/GitLab API 拉取 release 日志的适用场景
如果你没权限改本地提交规范，或项目用的是 GUI 提交（比如 VS Code Git UI），git log 和 standard-version 都不可行，就得绕路走 API。
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- GitHub：
curl -H "Accept: application/vnd.github+json" https://api.github.com/repos/{owner}/{repo}/releases，解析body字段 - GitLab：
GET /projects/:id/releases，注意要传private_token，且免费版只返回最近 20 个 release - 风险点：API 返回的 changelog 是人填的，可能为空、格式混乱、甚至写“同上一版”，没法做自动化比对
changelog 文件怎么更新才不冲突
多人并行发版时，CHANGELOG.md 极易冲突——因为所有分支都在往同一个文件末尾追加内容。这不是 Git 的问题，是写法问题。
- 别让每个 PR 都改
CHANGELOG.md：改了也白改，merge 顺序一变，内容就乱 - 正确做法：只在发版分支（如
release/1.4）上由standard-version一次性生成，且禁止手工编辑 - 如果必须人工补条目（比如修复了没提 PR 的 hotfix），用脚本在指定位置插入，而不是 append——否则 git blame 失效，diff 也看不出谁改了哪行
实际跑通的关键不在工具链多炫，而在提交信息有没有被当回事。没人写 fix(ui): prevent null ref in dropdown，再好的 standard-version 也吐不出像样的 changelog。
