更新日志（Change Log）指南

迭代和团队开发中，为了让代码改动更加显而易见，一般需要在项目文件下添加一个更新日志。

更新日志，防止你的版本们变得疯狂。否则，我们可能要去再痛苦的读代码，这是一件成本很大的事。

你每一次改动后的更新日志，是对其他人是友善，也是对自己的谅解。

是什么

用来记录你对代码的改动。

规范

在一些 git 工具中，可以使用 commit 的 log 信息生成 Change Log。 如果你使用这些 git 工具，可能会存在一些不同的规范标准，目的是为了让程序好处理。

作为面向人类的帮助文件，更新日志实际上没有一定的规范，让人能看懂就行。规范只是约定成俗和经验。

放在

• 项目文件的最外面的文件夹里

名字

一般是下面几种，都行

• CHANGELOG.md
• CHANGELOG
• CHANGELOG.txt

语法

• markdown
• 只能 markdown
• 最好不用别的，markdown 还是太权威了

形式

默认可以用中文，国际场景下要用英文

# Change Log

## version (date)

### type

- item
- item

## version (date)

### type

- item
- item

### type

- item
- item

标题

• Change Log
• 更新日志

版本

• 按照版本号规范

日期

• *（good）*2025-10-18
• *（bad）*2025.10.18，2025/10/18，18-10-2025

type 类型

• 新增（Features）：新增功能。
• 修复（Fixed）：修复 bug。
• 变更（Changed）：对于某些已存在功能所发生的逻辑变化。
• 优化（Refactored）：性能或结构上的优化，并未带来功能的逻辑变化。
• 即将删除（Deprecated）：不建议使用 or 在以后的版本中即将删除的功能。
• 删除（Removed）：已删除的功能

很接近 GIT commit 的格式，但其实略有不同：

• feat：新功能（feature）
• fix：修补bug
• docs：文档（documentation）
• style： 格式（不影响代码运行的变动）
• refactor：重构（即不是新增功能，也不是修改bug的代码变动）
• test：增加测试
• chore：构建过程或辅助工具的变动

item 规范

1. 动词开头
2. 使用第一人称现在时

例子

下面是一个完整（大概？）的更新日志：

# 更新日志

## 1.2.2 (2012-06-14)

### 更新

- 添加了错误处理函数

### 修复

- 修复了开机不受控的 BUG

## 1.2.3 (2012-07-02)

### 更新

- 添加了用户提示

### 优化

- 改变了用户交互逻辑