规范 前言作为一个软件开发者, 我是不是非要给我的那个项目去整一本更新日志, 也就是大家平常简称的那个小标签所代表的内容呢。如果你在维护一个开源项目, 或者是公司内部的底层技术产品, 那么提供更新日志 是必需的。开发者用户很可能需要从一个比较低版本的软件升级到最新的版本, 而发布说明文档 可以帮助他们了解新版本有哪些变化内容。如果你在开发一个业务应用系统, 那么在技术层面上讲, 提供上述内容不是强制性的必需品。然而, 如果你能提供一个清晰的记录, 效果会更好一些, 因为其他协作人员或者是未来接手工作的交接方, 能够比较直观地看到这个业务流程逻辑的演变过程是怎么样的。既然Git规范已经明确了对于Git提交日志格式的具体约束, 那么为何还需要进一步地、另行地对相关格式进行约束呢?就算你规定了 Git log 输出的样式, 你也不能够直接把 Git log 的内容导出来变成一个很好的东西。因为那个东西里面要写的那些内容, 需要被提炼一下, 还需要归纳一下顺序, 还要对信息做减量的处理, 把这些没用的噪音去掉。所以, 手动地去写它, 还是比机器自动生成更好的选择。不管你选的是手动手写, 还是让它自动去生成, 那个文档的格式, 都不能直接把 Git log 原来的格式拿过来就用。这两个事情之间, 既有不一样的地方, 也有有关联的地方, 这两种区别和联系是同时存在的。1. 是那个文件, 也就是文件的格式。那些被大家所推荐的, 并且在标准里面已经规定好的格式呢, 是这样的:# 更新日志## []() ()###* desc* desc###* desc* desc详细规则如下2.第七点是带有推荐标识的内容, 这里涉及到对更新描述desc里面的信息进行修改, 操作者必须在执行之前充分地了解并特别注意以下这些方面。请使用完整句子进行书写, 在标点符号方面遵守常规文档格式规范, 如果遇到英文部分则确保句首字母大写。 时态选择应一律使用一般现在时避免使用过去时态, 尽管阅读时所涉及的内容均发生在过去。 这样做能够更简洁明确, 也更容易保持全文一致性。句式结构应采用祈使句形式, 即一般情况下不要添加主语, 因为绝大多数情况下的主语默认为作者「我」。需要明确标注所修复的问题。假如曾经有过Issue的提及, 那么在句子末尾的位置增加该Issue的ID以及对应的链接即可。下面是样本示例。# 更新日志## [4.6.0](https://github.com/ant-design/ant-design/compare/4.5.4...4.6.0) (2020-08-23)### 新增- 新增图片组件 Image。- Table 新增 sticky 属性以支持固定表头和滚动条。[#25939](https://github.com/ant-design/ant-design/pull/25939)### 修复- 修复 Pagination 字体相关样式问题。[#26230](https://github.com/ant-design/ant-design/pull/26230)- 修复 Space children 有时会重新渲染的问题。[#26219](https://github.com/ant-design/ant-design/pull/26219)### 优化- 用 hooks 重构 Upload。## [4.5.4](https://github.com/ant-design/ant-design/compare/4.5.3...4.5.4)(2020-08-12)### 新增- 新增 badge-color Less 变量。### 修复- 修复 Form.Item 在 hidden 时引用 Less 样式时失效的问题。[#26152](https://github.com/ant-design/ant-design/pull/26152)参考资料