Git Commit Message规范

Git Commit Message 规范在现在的团队多人协作开发中越来越重要，已经成为一种新的标准实践。尤其是在一些大型项目和追求高质量和可维护性的项目中。遵循一定的规范，能为我们带了很多好处。比如：

• 按照规范的提交信息有助于确保每个提交的信息都是清晰且一致的，使得其他开发者能够迅速理解提交的目的和影响。
• 统一的格式让提交信息更易于阅读，特别是在查看提交历史或使用自动化工具生成变更日志时。
• 使用特定的类型（如 feat, fix, docs）可以传达提交的性质，帮助团队识别哪些是新功能，哪些是修复，哪些是文档更新等。
• 清晰的提交信息减少了需要额外沟通的情况，因为大部分信息都可以从提交记录中直接获取。

需要注意的是，规范化同时也会带给我们一些缺点，请在权衡利弊下使用。

• 对于新加入团队的同事来说，需要一定的时间，来学习相关提交规范。
• 过度规范的提交格式，对于一些简短的描述解可以解决的提交，或者小型紧急的修复优化可能是一种新的负担。
• 全部统一提交规范可能需要额外的工具或脚本来验证提交信息的格式，或者需要有人能有review提交信息。这增加了维护成本。

整体示例

在这里我提供一种比较常见、简洁的提交规范。能帮我们快速获取提交信息，又不需要花费太多的维护和学习成本。

1. 整体提交格式

[TYPE]:[相关需求或者BUG编号][修改或者新增模块-具体操作]

例如:

git commit -m '[fix]:[BUG_20201205_01][用户列表-修复搜索错误]'

2. 无编号情况

当我们的一写紧急BUG或者需求没有相关编号时，我们可以直接省略编号，只保留[]符号。

例如：

git commit -m '[fix]:[][用户列表-修复搜索错误]'

git commit -m '[feat]:[][用户列表-添加地址信息]'

3. 全局修改情况

在修改全局方法或者样式时，没有具体的模块。在添加提交信息时我们可以直接省略掉具体模块或者添加为全局方法、全局样式等。

例如：

git commit -m '[feat]:[BUG_20201205_01][文档导出]'

git commit -m '[style]:[][全局样式-顶部导航栏调整]'

4. 多个模块功能情况

我们有时候一次提交，修改了多个功能和模块，我们需要使用&链接多个提交信息。

例如：

git commit -m '[feat]:[BUG_20201205_01][文档导出]&[style]:[][全局样式-顶部导航栏调整]'

TYPE 类型

这里只列举了一些前端开发中常用的type列表。