20、Git与敏捷开发：Git与Jira/Trello的集成、分支命名规范、提交信息规范（Conventional Commits）
聊到敏捷开发，很多团队只关注站会和迭代计划，却忽略了版本控制这个底层支撑。说实话，Git 用得好不好，直接决定了你们团队是「真敏捷」还是「假敏捷」。我见过太多团队，每天站会开得热火朝天，一 merge 代码就鸡飞狗跳。
这一章，我把自己在几个项目里踩过的坑、总结出的套路，一次性讲清楚。核心就三件事：工具怎么连、分支怎么起名、提交信息怎么写。
20.1 为什么敏捷开发离不开规范的 Git 流程？
敏捷开发讲究快速迭代、持续交付。你想想看，如果每个开发者的分支命名乱七八糟，提交信息全是「fix bug」「update」，那项目经理看板上的卡片跟代码仓库之间就是断开的。出了问题，想回滚都不知道该回哪个提交。
我个人习惯把 Git 流程看作敏捷开发的「高速公路」：
- Jira/Trello 是导航仪，告诉你该去哪
- 分支命名规范 是车道标识，谁在哪个车道一目了然
- Conventional Commits 是行车记录仪，每一步都有据可查
三者配合好了，团队协作效率能翻倍。我在项目中遇到过最极端的情况：一个紧急线上 bug，从接到 Jira 通知到修复上线，只用了 15 分钟。为什么这么快？因为流程是通的，工具是连的，规范是刻在骨子里的。
20.2 Git 与 Jira/Trello 的集成
先说工具集成。说白了，就是让代码仓库里的操作，能自动同步到项目管理工具上。
20.2.1 与 Jira 集成
Jira 的集成方式比较成熟。我常用的做法是：
- 在 Jira 中启用 DVCS 插件（Distributed Version Control Systems）
- 关联 GitHub/GitLab 账号，授权 Jira 读取仓库
- 在分支名和提交信息中引用 Jira 编号，比如
PROJ-1234
集成之后，你在 Jira 的卡片上就能直接看到：
- 这个需求对应的所有分支
- 每次提交的代码变更
- Pull Request 的状态
嗯，这里要注意：Jira 的编号必须写对。大小写敏感，连字符不能少。我曾经因为写了个小写的 proj-1234，结果 Jira 没识别到，导致那个提交在卡片上消失了三天。
20.2.2 与 Trello 集成
Trello 的集成更轻量。我一般用 Power-Ups 里的 GitHub 或 GitLab 插件：
- 在 Trello 卡片上添加 Power-Up
- 授权后，可以直接在卡片上创建分支
- 提交信息里带上卡片链接，Trello 会自动生成评论
不过说实话，Trello 的集成深度不如 Jira。如果你团队规模超过 10 人，我建议还是上 Jira。Trello 更适合小团队快速试错。
20.3 分支命名规范
分支命名这件事，看起来简单，但坑特别多。我见过最离谱的分支名：my-branch、test123、fix…… 你想想看，项目上线后出问题，你看到 fix 这个分支，你知道它修的是什么吗？
我推荐的分支命名规范，基于 Git Flow 和 GitHub Flow 做了改良：
| 分支类型 | 命名格式 | 示例 |
|---|---|---|
| 主分支 | main 或 master |
main |
| 开发分支 | develop |
develop |
| 功能分支 | feature/<Jira编号>-<简短描述> |
feature/PROJ-1234-user-login |
| 修复分支 | fix/<Jira编号>-<简短描述> |
fix/PROJ-5678-null-pointer |
| 热修复分支 | hotfix/<Jira编号>-<简短描述> |
hotfix/PROJ-9012-payment-error |
| 发布分支 | release/<版本号> |
release/v2.1.0 |
核心原则：分支名必须能让人一眼看出「这是什么类型」「对应哪个需求」「大概做什么」。不要用拼音，不要用无意义的数字。
我在项目中遇到过最经典的案例：一个同事创建了分支 feature/123，结果三天后他自己都忘了 123 是哪个 Jira 卡片。后来我们强制要求：分支名里必须包含 Jira 编号和英文描述，中间用连字符分隔。
20.4 提交信息规范（Conventional Commits）
提交信息这件事，我花了好几年才真正重视起来。以前我也觉得「写那么详细干嘛，代码能跑就行」。直到有一次，线上出了严重 bug，需要回滚到某个版本。结果一看提交历史：
fix bug
update
update again
fix
final fix
really final fix
我当时就崩溃了。这谁看得懂？从那以后，我强制团队使用 Conventional Commits 规范。
20.4.1 规范格式
Conventional Commits 的格式很简单：
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
常用的类型有：
| 类型 | 含义 | 示例 |
|---|---|---|
feat |
新功能 | feat: add user login page |
fix |
修复 bug | fix: resolve null pointer in payment |
docs |
文档变更 | docs: update API reference |
style |
代码格式调整 | style: format code with prettier |
refactor |
重构 | refactor: extract payment service |
test |
测试相关 | test: add unit tests for login |
chore |
构建/工具变更 | chore: update dependencies |
20.4.2 结合 Jira 编号
在敏捷开发中，提交信息里一定要带上 Jira 编号。我习惯的格式是：
feat(PROJ-1234): add user login page
- Implement OAuth2 authentication
- Add login form validation
- Update user session management
Closes PROJ-1234
这样，Jira 会自动识别这个提交，并在卡片上显示。而且 Closes PROJ-1234 这个脚注，还能自动关闭 Jira 卡片。省事吧？
小技巧：可以用 git commit --template 设置提交模板，或者用 commitizen 这类工具，自动生成符合规范的提交信息。我团队现在全员用 commitizen，再也没人写「update」了。
20.5 整体流程与知识体系
下面这张图，是我自己总结的 Git 与敏捷开发协作流程。你看一遍，基本就明白这三者怎么配合了。
总结一下：工具集成解决「信息同步」问题，分支命名解决「代码组织」问题，提交规范解决「历史追溯」问题。三者缺一不可。
20.6 避坑指南
最后，分享几个我亲身踩过的坑：
- 分支名不要用中文。我曾经在某个项目里看到
feature/用户登录，结果在终端里显示乱码，根本没法用。 - 提交信息不要写「fix bug」。这种信息等于没写。至少要写清楚「修了什么 bug」「怎么修的」。
- Jira 编号一定要大写。小写字母在某些插件里识别不了，别问我怎么知道的。
- 不要在一个分支里做多个需求。每个分支只做一个 Jira 卡片，这样回滚和代码审查都方便。
警告：如果你团队还没用 Conventional Commits，我建议从下个迭代就开始推行。别等到代码历史乱成一锅粥再后悔。刚开始可能会有点不适应，但坚持两周，你就会发现——真香。
好了，Git 与敏捷开发的集成就聊到这儿。记住：规范不是束缚，而是效率的保障。你想想看，当你的团队每个人都能写出清晰的分支名和提交信息，项目经理在 Jira 上能直接看到代码进展，那才是真正的敏捷。