第三章：版本控制与Git工作流
聊到交易系统的运维自动化，版本控制是绕不开的基石。我见过不少团队，代码管理混乱，上线全靠「手传」。说实话，这在交易系统里是致命的。一次错误的合并，可能让整个交易链路瘫痪。
这一章，我们聚焦Git。不是讲那些「git add、git commit」的基础命令——那些你翻文档就能学会。我想聊的是：在交易系统这种高可用、高并发的场景下，Git工作流该怎么设计？
3.1 Git基础操作：不只是三板斧
先过一遍核心操作。嗯，这里我假设你已经会用Git了，但有些细节值得再提。
3.1.1 提交与回滚
提交信息怎么写？我个人的习惯是：动词开头，描述做了什么，为什么做。比如：
fix: 修复行情网关连接超时导致的重连风暴
- 增加连接超时后的指数退避重试
- 修复重连时未清理旧连接句柄的问题
- 相关JIRA: TICKET-1234
为什么要这么写？因为交易系统的日志审计需要追溯。你想想看，如果某次上线后行情断了，你翻git log看到「fix bug」——这跟没写一样。
git push --force。我曾经见过一个同事，因为force push把别人的提交覆盖了，导致回滚时找不到历史版本。那次事故，我们花了整整一个下午才恢复。
3.1.2 分支管理的基本操作
分支操作其实不复杂，但要注意一点：交易系统的分支命名要有规范。我建议这样：
| 分支类型 | 命名格式 | 示例 |
|---|---|---|
| 功能分支 | feature/<模块>-<描述> | feature/order-fix-timeout |
| 修复分支 | hotfix/<问题编号> | hotfix/TICKET-5678 |
| 发布分支 | release/<版本号> | release/v2.3.1 |
说白了，命名规范不是为了好看，是为了让CI/CD流水线能自动识别分支类型，做不同的处理。比如hotfix分支，应该跳过某些测试，直接走紧急发布流程。
3.2 分支策略：选对模式，少踩坑
分支策略的选择，直接决定了你的发布节奏和回滚能力。交易系统对稳定性要求极高，所以策略选择要慎重。
3.2.1 GitFlow：适合复杂发布流程
GitFlow是经典的分支模型。它有master、develop、feature、release、hotfix五种分支。结构清晰，但流程繁琐。
我个人的经验是：GitFlow适合那些有固定发布周期的交易系统。比如每周五发布一次，有严格的测试和审批流程。但如果你团队小、发布频繁，GitFlow会让你累死。
3.2.2 Trunk-Based Development：适合高频发布
Trunk-Based Development（主干开发）是另一种极端。所有开发者都在main分支上工作，通过短生命周期的特性分支（通常不超过一天）来隔离代码。
为什么交易系统也可以用Trunk-Based？因为高频交易系统需要快速响应市场变化。你想想看，如果某个策略参数需要紧急调整，你还要走GitFlow那一套流程——等分支合并完，行情都变了。
但Trunk-Based有个前提：必须有完善的自动化测试和代码审查。否则，一次错误的提交就能让主干崩掉。我在项目中遇到过这种情况，那次是因为一个同事忘了跑单元测试就push了，结果导致行情计算模块全部报错。
3.2.3 两种模式的对比
| 维度 | GitFlow | Trunk-Based |
|---|---|---|
| 发布频率 | 低（周/月） | 高（天/小时） |
| 分支数量 | 多 | 少 |
| 合并冲突 | 较少 | 较多 |
| 回滚难度 | 容易 | 中等 |
| 适用场景 | 有固定发布周期的系统 | 高频迭代、快速响应的系统 |
我个人建议：交易系统的核心模块（如订单路由、风控）用GitFlow，非核心模块（如报表、监控）用Trunk-Based。这样既保证了核心模块的稳定性，又兼顾了非核心模块的迭代速度。
3.3 代码审查流程：不只是走形式
代码审查（Code Review）在交易系统里不是走过场。它是防止「线上事故」的最后一道防线。
3.3.1 审查什么？
我总结了几点：
- 逻辑正确性：代码是否实现了需求？有没有边界情况没处理？
- 性能影响：这段代码会不会导致延迟增加？有没有不必要的锁？
- 安全性：有没有SQL注入？有没有敏感信息泄露？
- 可维护性：代码是否清晰？有没有注释？命名是否规范？
嗯，这里要特别强调一点：交易系统的代码审查，一定要关注「并发安全」。我曾经审查过一个订单处理模块的PR，发现开发者用了HashMap而不是ConcurrentHashMap。如果那次没发现，线上并发一高，订单数据就全乱了。
3.3.2 审查流程怎么走？
我建议的流程是这样的：
- 开发者提交PR，描述清楚「做了什么」和「为什么做」
- CI自动运行单元测试和代码扫描
- 至少两名审查者review代码
- 审查者提出修改意见，开发者修改
- 所有问题解决后，合并到目标分支
3.3.3 避坑指南
我曾经犯过一个错误：为了赶上线时间，跳过了代码审查。结果那次上线后，行情数据出现了偏差，导致策略交易亏损。从那以后，我定了一条铁律：任何代码，不经过审查，不准上线。
还有一点：审查者不要只看代码，还要看测试用例。如果PR没有对应的测试，或者测试覆盖率不够，直接打回去。交易系统的每一行代码，都应该有对应的测试覆盖。
3.4 本章知识体系
下面这张图，是我对本章内容的总结。你可以把它当作一个「速查表」：
好了，这一章的内容就到这里。版本控制看似简单，但真正用好它，需要结合业务场景来设计。交易系统对稳定性的要求，决定了我们不能照搬互联网公司的做法。GitFlow也好，Trunk-Based也罢，适合你的，才是最好的。