PLC 程序版本管理：从 U 盘拷贝到 Git 的落地实践

PLC 程序最怕的不是写错，是改完找不回。见过太多现场：U 盘里躺着"最终版_v2_真的最终版"，出了问题没人敢回滚。把 IT 那套版本管理搬过来，其实不难：

1. 先解决"可 diff"的问题
主流 PLC 编程软件都支持导出为文本/XML 格式。约定：每次下载前先导出、提交，提交信息写清楚改了什么、为什么改（比如"conveyor2 光电延时 200→500ms，解决误触发"）。

2. 分支策略从简
main 分支 = 当前运行版本，dev = 调试中。现场紧急改完，第一时间 merge 回 main 并打 tag（日期+设备号）。别搞复杂 flow，现场工程师记不住。

3. 回滚流程要演练
真出事时，正确姿势是：切 tag → 导出下载 → 验证运行。建议每季度演练一次，不然紧急时刻没人敢动手。

4. 权限与备份
Git 仓库放内网服务器，每天自动备份。离职交接时，仓库就是交接文档。

我们推行后，版本混乱导致的停机基本归零。代价是前期要花一下午定规范、做培训。

你们厂现在程序备份是怎么做的？有没有因为版本混乱吃过亏？

版本管理这条路我们也很认同，补充落地时三个「容易半途而废」的点：

1. 导出格式要固定：同一项目锁定同一种可 diff 导出（XML/文本），并写进项目 README；否则 A 用完整项目包、B 用部分导出，Git 上根本比不动。
2. 下载门禁：把「导出并 push 成功」做成下载前检查项（哪怕是清单勾选），比事后补交可靠。紧急在线改也要在当班结束前补提交。
3. 回滚演练别只演「能下载」：还要演「下载后 I/O 强制表、安全回路自检、关键设备联锁」是否通过，否则大家还是不敢切 tag。

权限上建议至少区分「能 push main」和「只能推 dev」；现场账号不要共用。有用过厂商自带版本服务器、后来迁到 Git 的朋友，欢迎对比一下迁移成本。