产品更新日志维护和方案

为什么需要更新日志#

更好配合 git tag 和 npm version 进行 版本管理，便于开发者回想各个版本都编写了哪些代码，并基于日志和 git 操作回溯相应版本进行分支开发。

便于用户了解 版本 变动（新功能和修复）

方案思考#

有余目的主要是两个，一个是方便开发者管理理解代码版本，一个是方便用户了解变化。

所以可以将 git 和 CHANGELOG.md 结合起来，使 CHANGELOG 源于 git commit，这样就可以很好的满足上述两个目的：开发者根据 CHANGELOG 和 git commit 定位代码提交，用户根据 CHANGELOG 了解版本变化。

所以方案大概思路：版本管理联动日志生成，根据 git history 自动生成 CHANGELOG.md

一些实现关键点思考#

1. 生成 CHANGELOG.md 的可读性要高：让 开发者 和 用户 都能清晰的了解版本变化
2. 可以根据规则从 commit message 中提取出有效信息并分类
3. 可以结合 git tag 进行版本管理（npm version 会自动创建对应版本的 git tag）
4. * 每次 release 都会在 github 仓库新建对应的 release 版本 并填入相应 变更 内容
5. * 每次 release 都会自动 发布到 npm

期望效果#

开发者只需关注开发内容和发布节点即可，不需要关注版本号和 CHANGELOG.md 的维护。每当开发者认为当前分支代码可以发布，他只要将分支合并到 release 分支，然后将分支推到 github 即可。版本管理、CHANGELOG.md 生成、github release 发布都会自动完成。

git history

commit $HASH
Author: $AUTHOR
Date: $DATE
    feat: add a new feature

commit $HASH
Author: $AUTHOR
Date: $DATE
    this a normal commit which should be ignored

commit $HASH
Author: $AUTHOR
Date: $DATE
    fix: fix a bug (#111)

自动生成

CHANGELOG.md

# Changelog

## [1.0.0] - 2023-03-05

### Added

- add a new feature

### Fixed

- fix a bug (#111)

参考文献#

如何维护更新日志 Conventional Commits vite