分享一套自用的git提交规范，可清晰的识别到关联的任务/bug
一、提交信息的基本结构
推荐使用约定式提交的一种变体，结构如下：
<类型>(<范围>): <主题>[#<禅道-ID>]<正文>（可选）<脚注>（可选）一个完整的、优秀的示例：
feat(用户模块): 增加用户手机号绑定功能 [#12345]
- 新增手机号验证接口（/api/user/bind_mobile）
- 用户表增加 mobile 和 mobile_verified 字段
- 添加发送短信验证码的功能
关联禅道需求: http://your-zentao-domain/zentao/story-view-12345.html二、核心组成部分详解
1. 类型 (Type) - 必选
表示本次提交的意图。以下是类型定义：
| 类型关键字 | 含义 | 适用场景 | 禅道关联 |
|---|---|---|---|
feat | 新功能 | 开发新的需求、功能 | 关联 需求ID (如 #123) |
fix | 修复Bug | 修复测试提出的或已知的Bug | 关联 BugID (如 #456) |
docs | 文档更新 | 修改文档（如README、接口文档），不涉及代码 | 可关联需求/BugID，或无 |
style | 代码样式 | 调整代码格式、缩进、分号等（不改变逻辑） | 通常无关联 |
refactor | 代码重构 | 重构代码，既非修Bug也非加功能 | 可关联需求ID（如性能优化需求） |
test | 测试相关 | 增加或修改测试用例 | 可关联需求/BugID |
chore | 杂项事务 | 构建流程、依赖管理、工具脚本（如webpack配置） | 通常无关联 |
2. 范围 (Scope) - 可选
用括号括起来，说明提交影响的范围。这有助于快速定位变更。
- 例如：
用户模块、订单模块、登录页、API、数据库等。 - 如果修改范围很杂或难以概括，可以省略
(scope)。
3. 主题 (Subject) - 必选
对本次提交的简短描述，不超过50个字符。
- 要求：
- 使用祈使句、现在时态（如"增加"，“修复”，“更新”，不要用"增加了"，“修复了”）。
- 首字母不要大写。
- 结尾不要加句号。
4. 禅道 ID - 强烈推荐
这是与禅道联动的关键！使用 # + ID 的形式。
- 格式：
[#12345] - 位置： 通常放在主题的末尾。
- 作用： 很多工具（如GitLab, Jenkins）可以自动解析这个格式，生成超链接。即使不能，也极其便于人工搜索。
5. 正文 (Body) - 可选
在主题之后空一行，编写更详细的说明。
- 写什么：
- 提交的动机：为什么要这样修改？
- 与之前行为的对比：修改了什么？是怎么实现的？
- 需要注意的** breaking changes **（不兼容的变动）。
- 格式： 每行不超过72字符，使用空格缩进的列表项会让阅读更清晰。
6. 脚注 (Footer) - 可选
通常用于放置不兼容的变动（以 BREAKING CHANGE: 开头）或关闭Issue（如 Closes #123, #245）。在你的场景下，可以放禅道需求的完整URL。
三、具体示例
示例1：完成一个需求
禅道需求： ID 为 10086，标题是“【用户中心】需要支持修改头像功能”
feat(用户中心): 支持用户上传和裁剪头像 [#10086]
- 新增头像上传接口 POST /api/user/avatar
- 新增图片裁剪组件（基于Cropper.js）
- 用户表增加 avatar_url 字段存储头像地址
See: http://zed.xxx.com/zentao/story-view-10086.html示例2：修复一个Bug
禅道Bug： ID 为 50020，标题是“商品详情页加入购物车按钮点击无效”
fix(商品页): 修复加入购物车按钮点击无效的问题 [#50020]
修复了因事件绑定函数名错误导致点击无效的问题，将 `addToCart` 更正为 `addToCart`。
See: http://zed.xxx.com/zentao/bug-view-50020.html示例3：处理多个任务（一次提交解决一个需求和一个Bug）
feat(订单): 增加订单导出为Excel的功能 [#10010]
fix(订单): 修复导出列表时间显示错误的问题 [#50015]
- 新增 POI 依赖用于生成 Excel
- 修复时区转换工具类的一个逻辑错误
)
