4. 版本控制工具选型与集成

在 Schneider 自动化项目中，版本控制工具的选择不能只看“谁更流行”，而要先看被管理对象的物理形态。一个典型的 EcoStruxure Control Expert（原 Unity Pro）项目目录里，往往同时存在 .sta、.stu、.stx 等二进制工程文件，.xvm、.xso 等导出交换文件，以及 .pdf、.xlsm、.zip 归档包。这些文件大多不是纯文本，Git 的逐行差异算法对它们几乎无效，一次“保存”就可能让整个文件哈希变化。因此，选型的核心矛盾是：工具能否在二进制、大文件、非文本文件场景下，仍然提供可追溯、可比较、可回退的工程能力。

三种工具在自动化工程中的定位差异

Git 是分布式版本控制系统，每个克隆都是完整仓库，分支和合并极轻量，适合并行开发和离线提交。但 Git 默认按行比较文本，对二进制文件只能判断“变了/没变”，无法展示内部差异；同时仓库体积会随二进制文件每次提交线性膨胀。SVN 是集中式系统，支持目录级锁定（svn lock），对“同一时刻只允许一人改一个程序文件”的串行协作天然友好，且可以通过 svn:needs-lock 属性强制加锁。TFS/Azure DevOps 则是微软系一体化平台，内置工作项、构建、发布流水线，并通过 TFVC 提供集中式版本控制，同时支持 Git 仓库，适合已经把项目管理、CI/CD 和权限体系放在同一平台上的团队。

把三者放在 Schneider 项目的真实约束下，可以形成如下判断：如果团队需要频繁分支、离线开发、与外部 Git 生态集成，Git 更合适；如果项目以少量工程师串行修改大型二进制程序为主，SVN 的锁定模型更省心；如果企业已经使用 Azure DevOps 做需求、测试和发布管理，TFS/Azure DevOps 的集成收益最大。关键不是“哪个最好”，而是“哪个与工程文件的存储和比较方式最匹配”。

二进制与大文件：真正决定成败的存储策略

无论选哪种工具，二进制工程文件都不能指望“自动合并”。在 Schneider 项目中，推荐的做法是把可比较的文本/XML 导出物作为主版本对象，把二进制工程文件作为受控附件。例如，在 Control Expert 中把程序导出为 .xvm 或 .xso，这些文件本质是结构化文本，可以纳入 Git 或 SVN 做逐行差异；而 .sta 原文件则通过 Git LFS 或 SVN 的二进制存储机制保留，用于最终下载和归档。

Git LFS 的配置方式如下，它把大文件替换为指针文件，真实内容存到 LFS 服务器：

# 安装 Git LFS 后，在仓库根目录执行
git lfs install

# 跟踪 Schneider 工程二进制文件
git lfs track "*.sta"
git lfs track "*.stu"
git lfs track "*.stx"
git lfs track "*.zip"

# 确认 .gitattributes 已生成
git add .gitattributes
git commit -m "配置 LFS 跟踪 Schneider 工程文件"

SVN 侧则通过属性控制锁定行为，避免两人同时修改同一个程序文件：

# 对二进制工程文件设置 needs-lock
svn propset svn:needs-lock "*" Project/PLC/Program.sta

# 提交属性变更
svn commit -m "为二进制工程文件启用锁定"

# 修改前先加锁
svn lock Project/PLC/Program.sta -m "修改主程序逻辑"

Azure DevOps 中，如果使用 TFVC，可以在服务器端设置“禁止多人同时签出”策略；如果使用 Git 仓库，则同样建议启用 LFS，并在分支策略中要求拉取请求附带导出文件差异说明。

差异比较：从“看不出”到“看得懂”

二进制文件无法直接比较，但可以通过“导出—比较—回写”的流程获得可读差异。以 Control Expert 为例，假设当前版本为 V1.2，工程师修改了主程序中的电机启动逻辑，操作顺序是：先从 V1.2 导出 Program_V1.2.xvm，修改后导出 Program_V1.3.xvm，然后用文本比较工具或 Git diff 查看两个 XML 文件的差异。差异会定位到具体的变量名、梯级编号或功能块参数，而不是整文件“二进制不同”。确认无误后，再把 .sta 原文件和 .xvm 导出文件一起提交，提交信息中注明“修改电机启动延时 2s→5s”。

集成方式：让版本控制嵌入工程流程

工具选型之后，集成方式决定它是否真正被用起来。Git 可以与 VS Code、Git Extensions 配合，在提交前自动检查是否遗漏导出文件；SVN 可以通过 TortoiseSVN 的客户端钩子，在加锁时提醒填写变更说明；Azure DevOps 则可以把构建流水线接到导出脚本上，每次提交自动生成 .xvm 并归档为构建产物。对于 Schneider 项目，推荐的最小集成闭环是：本地导出 → 差异检查 → 提交二进制与导出文件 → 流水线归档 → 发布时按标签下载。

最后需要强调：在 Schneider 自动化项目中，版本控制工具只是载体，真正决定治理效果的是文件分类策略和导出比较习惯。建议团队在选型后立即约定三件事：哪些文件进版本库、哪些文件走 LFS 或锁定、每次提交必须附带哪种导出文件。把这三条写进项目规范，比单纯争论 Git 还是 SVN 更有实际价值。