4. 版本控制与分支策略
在自动化项目中，代码不仅是“程序”，还包含 PLC 程序、HMI 画面、机器人程序、配置文件、通信点表、测试脚本与部署脚本。版本控制的目标不是“把文件存起来”，而是让团队能够并行开发、可追溯、可回滚、可评审、可发布。因此，分支策略必须与自动化项目的交付节奏、现场调试方式和发布流程相匹配。
一、核心原理：Git 工作流解决的是“变更如何汇合”
Git 是分布式版本控制系统，每次提交（commit）记录一个快照，分支本质上是指向提交的轻量指针。团队协作的关键在于：谁在什么分支上开发、变更如何进入主干、何时打标签、何时发布。常见工作流包括集中式、功能分支、GitFlow 与 Trunk-Based Development（TBD）。
在自动化项目中，推荐把“主干”视为始终可构建、可部署、可回滚的基线。任何未完成的现场调试代码，都不应长期停留在主干上。功能分支用于隔离风险，标签（tag）用于标记已发布版本，发布分支用于稳定化，热修复分支用于紧急处理现场问题。
关键原则：主干保持稳定；功能分支短生命周期；发布版本必须打标签；现场问题必须能追溯到具体提交；任何合并都必须经过代码评审与自动化检查。
二、方法流程：GitFlow 与 Trunk-Based 的适用场景
GitFlow 适合有明确版本发布周期、需要同时维护多个现场版本的项目。它包含 main、develop、feature/*、release/*、hotfix/* 等分支。优点是版本边界清晰，缺点是分支多、合并复杂，若团队纪律不足，容易出现“长期不合并”的分支。
Trunk-Based Development 强调所有开发者频繁向主干合并，通常每天至少一次。功能未完成时用特性开关（feature flag）隐藏，而不是长期开分支。它适合持续集成、持续交付能力较强的团队，能显著减少合并冲突，但对自动化测试与评审速度要求更高。
三、分支命名规范：让分支名自带信息
分支命名应包含类型、模块、简短描述、关联单号。推荐格式：类型/模块-描述-单号。例如：feature/plc-alarm-delay-1024、hotfix/hmi-login-timeout-2048。禁止使用 test、dev1、zhangsan 这类无意义名称。
| 分支类型 | 命名示例 | 用途 | 生命周期 |
|---|---|---|---|
| feature | feature/robot-gripper-1024 | 新功能开发 | 短，合并后删除 |
| release | release/v2.3.0 | 版本稳定化与验收 | 发布后保留标签 |
| hotfix | hotfix/plc-comm-loss-2048 | 现场紧急修复 | 极短，合并后删除 |
| bugfix | bugfix/hmi-trend-scale-3072 | 非紧急缺陷修复 | 短，合并后删除 |
| chore | chore/ci-pipeline-cache-4096 | 构建、配置、依赖维护 | 短，合并后删除 |
四、自动化项目中的版本管理实践
自动化项目的“版本”不仅是代码版本，还包括 PLC 程序版本、HMI 工程版本、机器人程序版本、配置文件版本与现场参数版本。建议采用单一可信源：所有可文本化的内容纳入 Git；二进制工程文件若无法 diff，则必须记录版本号、校验和与导出说明。
# 推荐的基础分支操作
git checkout main
git pull --rebase origin main
git checkout -b feature/plc-alarm-delay-1024
# 开发完成后，先同步主干再提交评审
git fetch origin
git rebase origin/main
git push -u origin feature/plc-alarm-delay-1024
# 发布时打标签，标签名与现场版本一致
git tag -a v2.3.0 -m "release v2.3.0: PLC alarm delay + HMI login fix"
git push origin v2.3.0
实践建议：在 CI 中增加分支命名检查、提交信息规范检查、PLC 程序编译检查、HMI 工程导出检查与配置文件校验。任何合并到 main 的变更，都必须通过自动化检查并至少一人评审。
五、案例与场景：现场紧急修复如何走分支
假设现场 v2.2.0 出现通信中断，需要紧急修复。正确流程是：从 v2.2.0 标签创建 hotfix/plc-comm-loss-2048，修复后同时合并回 main 与 release/v2.2.x，打新标签 v2.2.1，并记录现场升级说明。错误做法是直接在 main 上改完就发，导致修复内容与未发布功能混在一起，无法回滚。
六、误区与复盘
- 误区一：分支越多越安全。长期不合并的分支会积累冲突，最终变成“合并灾难”。
- 误区二：只管理代码，不管理配置。自动化项目的通信点表、报警阈值、配方参数同样需要版本化。
- 误区三：发布不打标签。现场出问题时无法定位具体版本，回滚也无从下手。
- 误区四：评审只看代码，不看工程文件。PLC/HMI 工程变更应附带导出对比说明与测试记录。
复盘要点：分支策略没有绝对最优，只有与团队规模、发布频率、现场维护复杂度匹配的方案。小团队可从简化 GitFlow 或短分支 TBD 起步，逐步补齐标签、评审、自动化检查与发布记录。
总结来说，自动化项目的版本控制应做到：主干稳定、分支短命、命名清晰、标签可追溯、配置同源、发布可回滚。把 Git 工作流与现场交付流程对齐，才能真正降低协作成本与发布风险。