3. 版本控制与分支策略
在医疗软件工程中，版本控制不只是“把代码存起来”的工具，它同时承担着变更记录、责任归属、可追溯性与审计证据的职责。无论是面向医院的临床信息系统、影像处理软件，还是符合 IEC 62304 的医疗器械软件，监管审查都会追问三个问题：这段代码是谁、在什么时候、因为什么需求或缺陷而修改的？它经过了哪些评审和测试？发布到现场的版本究竟对应哪一份源码？Git 本身不会自动回答这些问题，必须通过分支模型、提交规范和追溯机制把答案“固化”在仓库历史里。
分支模型：GitFlow 与 Trunk-Based 的取舍
医疗软件常见的分支模型有两类。第一类是 GitFlow：以 main 保存已发布版本，develop 作为集成分支，功能在 feature/* 上开发，发布前进入 release/* 做稳定化，紧急修复走 hotfix/*。它的优点是发布边界清晰、每个版本都有独立稳定期，适合版本节奏较慢、需要长期维护多个已上市版本的医疗器械软件，例如某型号监护仪固件需要同时维护 2.3、2.4 两个现场版本。
第二类是 Trunk-Based Development：所有开发者频繁向 main（主干）合入小批量变更，通常每天至少一次，配合特性开关（Feature Flag）隐藏未完成功能，发布时从主干拉出短生命周期的 release/* 分支。它适合持续交付能力强、有自动化回归测试和灰度发布机制的团队，例如云端 PACS 服务。其代价是对测试覆盖率和提交纪律要求极高，否则主干会长期处于不可发布状态。
选择的关键不是“哪个更先进”，而是发布频率、并行维护版本数量、回归测试自动化程度三者的匹配。下表给出一个可参考的判断依据（示例，非实测数据）：
| 判断维度 | 倾向 GitFlow | 倾向 Trunk-Based |
|---|---|---|
| 现场并行维护版本 | ≥2 个 | 通常 1 个 |
| 发布周期 | 数周至数月 | 数天至数周 |
| 自动化回归覆盖 | 可部分依赖人工 | 必须高覆盖 |
| 监管文档节奏 | 按版本成批归档 | 按变更持续归档 |
提交规范：让每条历史都成为审计线索
提交信息是审计追踪的最小单元。推荐采用 Conventional Commits 结构，并强制关联需求或缺陷编号。格式为：
<type>(<scope>): <subject>
<body>
Refs: REQ-1042
Reviewed-by: 张工
其中 type 建议限定为 feat、fix、docs、test、refactor、chore、security。医疗软件尤其要区分 fix（缺陷修复）与 feat（需求变更），因为前者可能触发 CAPA（纠正与预防措施）流程，后者需要走设计变更评审。示例：
fix(alarm): 修正心率报警阈值下限判断错误
原逻辑在 30 bpm 时误触发低限报警，改为 <= 30 才触发。
已补充单元测试 AlarmLimitTest#testLowerBoundary。
Refs: BUG-2087
Reviewed-by: 李工
为了让规范可执行，应在 Git 服务端或本地钩子中校验：提交信息必须匹配正则、必须包含 Refs: 字段、禁止直接向 main 推送。这样“追溯”不再依赖人的自觉，而是由工具强制。
代码追溯与审计追踪要求
医疗软件的追溯链通常要求从需求 → 设计 → 代码提交 → 构建产物 → 测试记录 → 发布版本双向可查。Git 侧需要做到：
- 提交与需求/缺陷双向关联：提交信息中的
Refs: REQ-1042可被脚本解析，生成追溯矩阵；反向也能从需求查到所有相关提交。 - 不可篡改的历史：对
main和release/*启用分支保护，禁止 force push 和删除；开启签名提交（GPG/SSH）验证作者身份。 - 评审留痕：合并请求（Merge Request）必须至少一名评审人批准，评审意见与批准记录随仓库保留，作为设计评审证据。
- 版本标识唯一：每次发布打带注释的标签（annotated tag），如
v2.4.0，标签信息中记录构建号、发布说明链接和对应提交哈希。 - 保留期限：按法规要求，医疗器械软件的技术记录通常需保存至产品停产后若干年，仓库与构建产物应纳入同一归档策略。
一个可落地的合规工作流示例
以 GitFlow 为例，一次缺陷修复的完整路径如下（示例流程）：
- 从
develop拉出hotfix/BUG-2087。 - 修改代码并提交，提交信息包含
Refs: BUG-2087与评审人。 - 推送后创建合并请求，CI 自动运行单元测试与静态检查，评审人批准。
- 合并回
develop与main，在main上打标签v2.4.1。 - CI 基于该标签构建产物，记录构建号与提交哈希，归档测试报告。
整个过程产生的提交、评审、标签、构建记录，共同构成该缺陷从发现到修复的可审计证据链。
无论选择哪种模型，核心目标一致：让每一次代码变更都能被解释、被追溯、被验证。分支模型决定变更如何流动，提交规范决定变更如何被记录，审计追踪要求决定这些记录如何被保存和检索。三者共同构成医疗软件在 Git 层面的合规基础。