前言
作为一个普通的开发者，我必须为我的项目维护一个更新日志（以下简称 changelog）吗？
- 如果你在维护一个开源项目，或者公司内部的底层技术产品，那么提供一个 changelog 是必需的。开发者用户很可能需要从一个低版本升级到最新版，changelog 可以帮助他们了解新版本有哪些变化。
- 如果你在开发一个业务应用，那么 changelog 不是必需的。然而提供一个 changelog 会更好，因为其他协作者或是交接方能更直观地看到业务逻辑的演变。
我记得你还约束了 Git log 的规范，那为何还要再规范 changelog 的格式呢？两者不是差不多？
- 即便是约束了 Git log 的规范，也无法直接将 Git log 导出一个良好的 changelog。因为 changelog 中描述的内容需要更加精炼和归纳，对信息降噪处理等等，因此手写 changelog 仍然是更好的选择；当然，不排除以后自动转换的可能。
- 不管是手写还是自动转换，changelog 的格式都不能直接照搬 Git log 的格式。这两者的区别与联系同在。
changelog 文件
changelog 文件必须取名为 CHANGELOG.md，存放在项目的根目录下，和 README.md、CONTRIBUTING.md 等并列，同时保持风格一致。
这种命名方式已然是国际通则，以下再阐释一番：
使用大写来表明本文件的重要性，相当于是项目仓库元信息的一部分。 使用 .md 作为后缀，而不是 .txt 或干脆不加后缀。使用标准 Markdown 语法，从而可以方便地渲染。
基本的 changelog 格式
# 更新日志
## [<version>] - <date>
### <type>
* <desc>
* <desc>
### <type>
* <desc>
* <desc>
[<version>]: <version-diff-url>
其中，按照最新的版本号在前的顺序排列。
词汇表
标题
标题部分使用固定的文案：「更新日志」。
如果是面向国际的项目，需要使用英文，则文案为「Change Log」。
version
版本号 version 即项目的每一个发布版所使用的版本号。版本号需遵循 SemVer 版本号命名规范。
注意：版本号前不要加 v。
另外，版本号建议增加一个链接，指向当前版本和上一个版本之间的 diff。详情可参考后文的样本示例。
date
发布时间 date 即版本发布时的所在日期。
日期采用 yyyy-MM-dd 的格式。
示例：
// good
2016-01-01
// bad
2016-1-1
20160101
type
更新类型 type 用以说明更新的方面。这里的 type 和 Git 提交日志中的 type 有所联系，然而并不一一对应。
同前面提到的「标题」部分，默认使用中文版本的词汇，如果是面向国际的项目，则使用括号中的英文版本。
type 的可选值如下：
-
新增（Features）：新增功能。可简写为
+ -
修复（Fixed）：修复 bug。
-
变更（Changed）：对于某些已存在功能所发生的逻辑变化。
-
优化（Refactored）：性能或结构上的优化，并未带来功能的逻辑变化。
-
即将删除（Deprecated）：不建议使用 / 在以后的版本中即将删除的功能。
-
删除（Removed）：已删除的功能。
desc
描述内容 desc 需要注意：
- 使用完整的句子。即在标点方面遵循一般的文档格式规范；如果使用英语，则句首大写。
- 时态方面使用一般现在时，不要用过去时态。虽然查看 changelog 时，changelog 内容本身都发生在过去，然而使用现在时的时态更简洁明确，并且更易达成一致性。
- 句式使用祈使句式。即一般情况不要增加主语。因为在绝大情况下，主语都是作者「我」。
- 注明修复的问题。如有提过 issue，则在句尾增加 issue 的 ID 和链接。
[^ KeepChangeLog](https://keepachangelog.com/zh-CN/1.0.0/)