企业官网建设流程全解析

简介：《TwinCAT 3 AdsGitServer的使用.pdf》面向使用 Beckhoff TwinCAT 3 进行 PLC 开发的自动化工程师与协同开发团队，聚焦在 TwinCAT 3.1.4024 及以上环境中直接借助 AdsGitServer 完成版本管理、减少外部 Git 工具依赖的问题。资源包仅含 1 个 PDF 文件，大小约 1.77MB，篇幅集中，便于按目录查阅与现场参考。文档围绕 Multiuser 启用、Git Server 初始化、提交与获取、历史版本比较及回退等环节展开，并整理 Init 创建失败、连续提交版本等常见问题的排查思路；同时涉及第二台 PC 从控制器装载不同版本 PLC 程序的操作说明。已有 373 人学习，适合需要快速了解控制器作为 Git Server 的用法、补齐版本管理流程与排错要点的初、中级 TwinCAT 开发者。

1. 从「改坏了想回退」说起：TwinCAT 3 AdsGitServer 到底能省掉什么

上周一个做产线改造的同行问我：PLC 程序已经改到第 7 版，客户现场跑下来却说第 3 版的节拍最稳，怎么退回去？我说，TwinCAT 3.1.4024 之后这活儿不用再装第三方软件——控制器本身就是一台 Git Server。TwinCAT 3 AdsGitServer 随 XAE/XAR 安装包一起安装，在系统服务列表里以独立服务的形式常驻，通过 ADS 通道对外提供版本仓库；开发端只要在 Multiuser Explorer 里点一次初始化，之后每次向控制器 Login 都会自动变成一次提交，历史版本、差异比较、单段代码接受、整版回退全在 IDE 里闭环。

它解决的不是「Git 好不好用」，而是「现场工程师不想为了版本管理再学一套命令行」这件事。适合三类人：一个人维护多台设备、需要留痕的；两台 PC 交替调试同一台控制器的；以及程序交付后还要被客户追问「这行什么时候改的」的。反过来，多人同时改同一份 PLC 代码的团队，它不是万能药，后面会讲边界在哪。

2. 把控制器变成 Git Server：版本、服务与插件四项硬前提

这一章全是准备工作，但恰恰是最容易翻车的地方。相当一部分「Init 失败」并不是 Git 的问题，而是版本没对齐、服务没起来或者插件没指到 Git 上。我一般把这四件事当成上电自检清单，一项一项过，不跳步。

2.1 XAE / XAR / 控制器系统三者的版本矩阵

官方手册里对这条其实写得比较松，但实测结论很硬：XAE（开发环境）和 XAR（控制器运行时）最好是同一个 Build，而且 Build 越高越省心。控制器侧要求 Windows 7 或 Windows 10（嵌入式版本同样算），TwinCAT 3.1.4024.15 或以上；开发 PC 侧同样是 3.1.4024.15 或以上。低于这个版本，Service 列表里根本不会有 AdsGitServer 这一项，你怎么找都找不到。

下面这张表是我自己测试时用的对照，实际项目按这个维度去核对即可：

还有一条手册没写、但实测很明显的经验：尽量用原厂的 IPC / EPC 系列控制器。在第三方 PC 上装 XAR 做这套测试，会出现各种零散问题——服务起不来、Init 卡住、Compare 打不开，排查起来像是玄学。我个人的做法是，只要要开 Multiuser，硬件就别省这一步。

2.2 安装包里自带的 AdsGitServer：怎么确认它在跑

AdsGitServer 不需要单独下载。开发笔记本上装完整安装包（形如TC31-FULL-Setup.3.1.4024.15.exe），控制器上装运行时安装包（形如TC31-XAR-Setup.3.1.4024.15.exe），Git Server 就跟着进去了。装完重启，进服务列表确认两个服务都在运行：

REM 查询 AdsGitServer 与系统服务的当前状态 sc query "TwinCAT3 AdsGitServer" sc query "TwinCAT 3 System Service" REM 查看启动类型，确认是自动启动而不是手动 sc qc "TwinCAT3 AdsGitServer"

sc query看的是STATE字段，必须是RUNNING；sc qc看的是START_TYPE，正常应该是AUTO_START。如果服务是STOPPED，先手动起一次，起不来就去事件查看器看服务启动报错——十有八九是安装没走完或者被杀毒软件拦了。这一步跳过的后果是：后面在 Multiuser Explorer 里点 Init，它会一直转圈或者直接报路由错误，而报错信息完全不会提示你「服务没起来」。

2.3 添加路由与把源码管理插件指向 Git

路由是 ADS 通道的基础。添加路由时顺手再确认一遍控制器的操作系统和 TwinCAT 版本，别用一条半年前建的旧路由去连一台刚刷过系统的控制器。路由通了，在开发 PC 的 TwinCAT 里还要做一次全局设置：主菜单「工具 → 选项」，找到源代码管理（Source Code Control）页面，把插件选成 Git。

这一步的意义在于：只有插件指向 Git，做版本比较时才会去打开 Git Server 上存的那份源代码，并且用集成的 TwinCAT 3.1 Project Compare Tool 来渲染差异。选错了插件（比如默认的其它源码管理插件），History 里点 Compare 要么没反应，要么弹出一个纯文本 diff，PLC 的 POU 结构完全看不出来。

2.4 Project Compare Tool 的 User Tools 配置

比较工具本身还需要一次配置，否则两个版本之间的 XML 差异没法按 PLC 的方式呈现。操作路径是：从编程 PC 的 TC3 图标进 Tool，打开 TwinCAT Project Compare，然后在主菜单里进Tool → Configure User Tools，点Export Configuration，选择 Git 插件，启用默认的全局 git 配置。

配置成功的标志很直观：后面在 History 里选中两个版本点 Compare，能看到按 POU 分组的树，差异以红色标注，双击红色节点能展开到具体代码行。如果这里没配好，你会看到一堆看不懂的原始文件对比，误以为是版本坏了。我见过有人因为这个把整个仓库删了重建，白丢一天。

3. 第一次 Init：把 PLC 项目纳入 Multiuser 版本管理

准备工作过了，接下来才是真正的动手环节。这一章的目标很具体：让一个空白的 PLC 项目在控制器上落地成一个 Git 仓库，并且完成前两次提交、看到历史、做一次回退。走完这一遍，后面双机协同就是同一套动作换个顺序而已。

3.1 启用 Multiuser 属性与仓库命名规则

新建 TwinCAT 项目、添加 PLC 程序之后，第一件事是打开 PLC 项目的属性，勾上启用 Multiuser。这个勾选是「这个项目归 AdsGitServer 管」的开关，不勾后面 Init 按钮点了也没用。

然后从主菜单「视图 → 其它窗口 → Multiuser Explorer」打开 Git 控制面板。面板里有两个关键输入项：ADS Route 和 Multiuser Repository。

• ADS Route 选你刚建好的那条到控制器的路由。
• Multiuser Repository 填仓库名，这个字符串就是将来控制器上仓库文件夹的名字，命名上建议用项目代号加版本，别用中文和空格。

这里有个小坑：选完路由、填好名称后，正常情况下 url 会自动生成；如果没有自动生成，删掉名称最后一个字符再补回去，url 就刷新出来了。这不是 bug，是界面刷新时机的问题，知道这一手能省掉一次重装。

3.2 Init local and Remote 在两侧各写了什么

点「Init local and Remote」，第一次会弹窗要求填 Update Message，这是第一次向控制器上传程序，填个Init就行。初始化成功后，界面上的 ADS Route 和 Multiuser Repository 会变成不可编辑状态——这就是成功的标志，改不动说明绑定生效了。

这一步在两侧各留下了一套结构：

• 控制器侧：默认仓库根目录下（C:\ProgramData\下的厂商目录里，MultiuserRepository）新建一个以你填的名称命名的文件夹，里面有一个Objects子目录。此后每次向控制器 Login，只要TwinCAT/3.1/Boot里的内容变化，Objects里的内容就跟着更新。
• 开发 PC 侧：PLC 项目目录下多出三个 Git 元数据文件和一个.git目录。

理解这一点很关键：Local 指的是开发 PC 上这个项目文件夹，Remote 指的是控制器上那个仓库文件夹。后面 Status 和 Conflict 界面里出现的 Local / Remote 字样，说的就是这两处，不是网络意义上的本地和远程服务器。

3.3 提交两个版本：Login 与 Update Message 的绑定关系

Git Server 跑起来之后，提交动作不需要你手动点「Commit」——每次向控制器 Login，它都会要求你填 Update 信息。这个设计挺讨巧的，把版本记录绑在了下载程序这个必经动作上，想忘都忘不了。

我按下面这个节奏做了两次提交，用来验证历史功能：

// 版本 V1.0 First Code：新建变量 x，递增步长 1 PROGRAM MAIN VAR x : INT; END_VAR x := x + 1;

// 版本 V1.0.1 Change Data：只改递增步长，变量不动 PROGRAM MAIN VAR x : INT; END_VAR x := x + 2;

第一次提交 Update 信息填V1.0 First Code，第二次填V1.0.1 Change Data。注意第二次只改了一个常量，这正是最能体现版本比较价值的场景——代码结构没变，只有一处数值不同，人工对比很容易看漏，差异视图里一眼就能看到。

Update 信息怎么写，我的习惯是「版本号 + 一句话动作」：V1.0.1 Change Data、V2.0 Change Para这样。别写「改了一下」「调试」这种，三个月后自己都看不懂。这是血泪经验，不是洁癖。

3.4 History、Compare、Get this version 三步回退

打开 Multiuser Explorer 的 History 页，点Show History，所有历史版本按时间线列出来，每一条对应一次 Login 时填的 Update 信息。这个列表是线性的——单人对单机开发时，线性结构其实是最好的，读起来就是一条修改脉络。

比较操作分两种：

• 只选一项，右键 Compare：该项与当前版本比较。
• 选两项，右键 Compare：这两项之间比较。

差异分三类：新增、删除、逻辑修改，不同处红色标记。双击某个红色 POU，展开到具体代码行，这时候就能看清是哪一个常量被改了。

如果只想把历史版本里的部分内容搬到当前版本，选中那处差异，在项目比较界面点感叹号上方的Accept Single、Accept Block或Accept All，回到当前 PLC 程序，代码就已经改过来了。这个功能在「新版本改对了两处、改坏了一处」的场景里非常好用，不用整版回退。

要整版回退，就在 History 里选中目标版本，右键Get this version。IDE 会弹一句File has been changed outside the enviroment. Reload the new file?——这里的 outside 指的就是 Compare Tool 从 Git Server 取了旧版本代码并改写了 POU 文件。

提示：这句提示不管点「是」还是「否」，代码都已经变了。Reload 只是决定要不要立刻刷新编辑器视图，不是「是否执行回退」的确认框。

4. 双机协同：第二台 PC 接入控制器仓库的完整链路

单机场景走通之后，真正有价值的是两台 PC 交替调试同一台控制器。这也是这套方案最容易被低估的地方：不需要任何一台常开的 Git 服务器，控制器就是那个汇聚点。下面按实际先后顺序走一遍。

4.1 第二台 PC 拿项目：上传源程序还是直接拷贝

第二台笔记本装同版本 TC3（同样 3.1.4024.15），添加到控制器的路由，然后要解决「项目从哪来」。两条路：

一是直接从前一台 PC 拷贝项目文件夹，最省事，前提是能拿到。二是从控制器上传源程序。这里要注意，上传的主要目的是拿到与控制器中正在运行的程序同名的项目，能不能读到完整 PLC 源代码不要紧——因为前一台 PC 未必把源代码下载到了控制器里。这个认知差异会让不少人卡住：以为上传失败就是环境坏了，其实是本来就没有。

项目拿到手后，先别急着改代码，把版本仓库接上再说。

4.2 初始化时的「Remote 已有数据」该怎么答

第二台 PC 上打开 Multiuser Explorer，ADS Route 选控制器，Multiuser Repository 从下拉菜单里选目标仓库（前提是你知道控制器上的仓库名）。点Init Local and Remote，系统会提示 Remote 中已经存在数据仓库，问要不要读取。

这里必须答「是」。答「否」的后果是本地初始化了一个空仓库，跟控制器上那份历史完全对不上，后面 History 里空空如也，等于把前一台 PC 的四个版本全丢了。这个过程本质上是把控制器上的仓库同步到第二台笔记本。

同步下来之后，还要从 History 里把当前版本装载一次，让本地项目文件和控制器上的最新状态对齐，然后再开始改代码。

4.3 提交两个版本并观察 History 合并结果

在第二台 PC 上继续改，按同样的节奏提交两次：

// 第二台 PC 提交 V2.0 Change Para：步长从 2 改为 10 PROGRAM MAIN VAR x : INT; END_VAR x := x + 10;

// 第二台 PC 提交 V2.0.1 Second Code：新增变量 y，引入依赖关系 PROGRAM MAIN VAR x : INT; y : INT; END_VAR x := x + 10; y := 2 * x;

第一次 Update 信息填V2.0 Change Para，第二次填V2.0.1 Second Code。提交完回 History 页看，列表里应该同时有第一台 PC 的两个版本和第二台 PC 的两个版本，四条排成一条线。如果只看到两条，说明 4.2 那步答错了。

4.4 回到第一台 PC：LocalsBehindRemote 的判读与恢复

现在回到第一台 PC，打开 History，会发现 Local 和 Remote 不一致：红色标出的是 Remote 新增的版本（第二台 PC 提交的），绿色标出的是当前 PC 保存的最新版本。这个颜色语义别记反了。

进 Status 页，提示LocalsBehindRemote——意思是本地程序版本比控制器上的旧。进 Conflict 页，提示本地丢失了远程的若干次修改。这时候点Get Latest，IDE 会提示程序从外部改动了，并列出与当前代码的区别，可以逐条 Accept 或拒绝，也可以直接关掉不予理会。

要拿到第二台 PC 的最新代码，最直接的做法是在 History 里选中V2.0.1，右键Get This Version，弹窗问是否装载，选「是」，本地项目就变成了第二台 PC 编辑的最新状态。再回 History 看，Local 和 Remote 已经对齐。

这套流程里有个容易忽略的细节：Get Latest拿到的是「远程最新」，Get This Version拿到的是「你选中的那一版」。前者适合日常同步，后者适合精确回退或取某个中间状态。两者混用是新手最常见的困惑来源。

5. 避坑与排查：五条翻车记录和一条不该碰的红线

这一章按「现象 → 原因 → 解决」来写，每条都是我在测试和使用过程中真实撞上的。你如果正在卡某一步，直接按标题找对应的现象就行。

5.1 五条高频踩坑记录

第一条：Init 反复失败，界面卡在初始化不动。

现象：点Init local and Remote之后长时间无响应，或者弹一个语焉不详的错误，重试多次结果一样。

原因：控制器侧的TwinCAT/3.1/Boot里残留着上一个项目的配置，同时开发 PC 侧的项目目录里也有旧的 Git 元数据，两边状态都对不上。这种情况在「同一台控制器换项目」时特别常见。

解决：两侧都要清干净。控制器侧把TwinCAT/3.1/Boot清空并重启控制器；开发 PC 侧手动删掉 PLC 项目目录下的 Git 文件和.git目录。

REM 在 PLC 项目根目录下清除本地 Git 元数据（删除前先确认路径！） cd /d D:\Projects\DemoPLC rmdir /s /q .git del /q .gitignore .gitattributes

注意：控制器上MultiuserRepository目录里的内容不必清空，那是历史仓库，将来还能用；要清的只是 Boot。这个区分很重要，清错了等于把历史版本全扔了。

第二条：Multiuser Repository 的 url 一直是空白。

现象：选了 ADS Route，名称也填了，但 url 字段不生成，Init 按钮点了没反应。

原因：界面刷新时序问题，尤其是在新建项目后第一次打开面板。

解决：把仓库名最后一个字符删掉再补回去，url 就会重新生成。属于操作层面的小技巧，不用重装、不用重启。

第三条：同一个文件夹被两套 Git 同时追踪，出现莫名其妙的状态错乱。

现象：提交后 History 里看不到新版本，或者本地文件状态与 Remote 对不上，但每一步操作看起来都正常。

原因：这个 PLC 项目文件夹既启用了 Multiuser（归 AdsGitServer 管），又用标准 Git 工具执行过git init。两套 Git 抢同一个工作区，必然冲突。

解决：二选一，不能并存。PLC 项目文件夹交给 AdsGitServer，非代码类文档目录交给标准 Git，物理上分开。这条是硬规矩，不是建议。

第四条：以为点「否」就没回退。

现象：Get this version之后弹File has been changed outside the enviroment，用户点了「否」，打开代码发现已经变了，怀疑是不是搞错了。

原因：这个弹窗只是在问要不要重新加载编辑器视图，文件本身已经被 Compare Tool 改写了。

解决：把它当成一个纯提示，不是确认框。执行回退之前先想清楚，别指望靠点「否」撤销。真要后悔，只能再Get this version回到原来那一版。

第五条：第三方硬件或版本不一致导致的「玄学」问题。

现象：在非原厂 PC 上装 XAR 做测试，服务起不来、Init 卡住、Compare 打开白屏，报错各不相同。

原因：XAE 与 XAR 的 Build 不一致，或者硬件本身不是这套功能的目标平台。

解决：先把 XAE 和 XAR 的 Build 对齐到同一版本，越高越好；开发环境优先用原厂控制器做验证。这条没有技巧，只有对齐。

5.2 使用范围与授权访问：什么时候别硬上

关于使用范围，说句不讨喜的实话：这套方案目前最舒服的场景是单人开发。每次修改有脉络可循，History 就是一条清晰的时间线，往前翻两页就能想起当时为什么改。

如果是多人同时改同一个 PLC 程序的不同部分，那就得提前把分工、代码编辑边界、上传下载顺序约定得非常细。约定不到位，History 会从「修改脉络」变成「一团乱麻」，最后还是要人工合并，反而不如老老实实分项目做。这一点在测试文档里也没回避。

关于安全，Multiuser 的文档里没有专门讲如何授权用户访问 Git Server。因为走的是 ADS 通道，所以 ADS 那一套安全方式都能套用——证书、预共享密钥、用户名密码这几种方式在 3.1.4024 里都已经支持。测试阶段为了省事可以完全不加密，但实际项目里，尤其是多人协同的时候，授权访问是绕不过去的一步，别默认它不存在。

6. 非 TwinCAT 文件怎么管：两套 Git 分工与一条硬边界

PLC 代码之外，项目里通常还有程序说明、设备操作手册、接线图说明这些文档。它们不在 TwinCAT 的管辖范围内，Multiuser Explorer里根本看不到，但这不代表没法留痕——开发 IDE 自带的团队资源管理器面板就能干这件事，它列出的本地 Git 存储库既包含 AdsGitServer 追踪的 PLC 代码仓库，也包含用标准 Git 工具追踪的普通文件夹。

具体操作分三步。第一步，在团队资源管理器里点「管理连接」回到主界面——这个按钮是迷路时的后悔药，任何时候点它都能回到起点。第二步，新建或添加存储库：新建是建一个空文件夹并启用 Git 管理，默认路径在用户目录的Source\Repos下；添加是接管一个已经在别处执行过git init的现有文件夹。第三步，在存储库配置主页里点「更改」，用加减号把文件加入或移出暂存区，然后提交临时数据，填上更新信息，比如V1.0.1，2021.06.07。

要提醒的是，团队资源管理器面板里的「解决方案」入口尽量不要用——新建和打开 TwinCAT 项目都有别的方式，而点「显示文件夹视图」会直接关掉当前 TwinCAT 项目，跳去资源管理器，打断工作流。

版本查看和恢复只能在标准的 Git 里做。在目标文件夹里右键进 Git Bash，用命令看历史、回退：

# 查看该文件夹的提交历史，一行一条 git log --oneline # 回退到上一个版本（丢弃工作区改动，谨慎使用） git reset --hard HEAD^ # 再次确认历史，应只剩回退后的那一条 git log --oneline

git log --oneline输出里，每条前面的短哈希是版本标识，后面是提交信息；HEAD^表示当前提交的父提交，--hard会同时重置工作区文件，所以执行前确认没有未提交的改动。回退之后打开那个被改过的文档，内容确实回到上一版——这是验证回退是否生效最直接的方式。

这张表最后两行是重点：AdsGitServer 的杀手锏是按 PLC 编程环境的方式做代码对比，标准 Git 做不到；但反过来，非代码类文件在标准 Git 里也只能看历史、不能像 PLC 那样比较合并回退。所以别指望一套工具通吃，PLC 代码归 AdsGitServer，文档归标准 Git，两套并行、各管各的文件夹。

还有一个更隐蔽的边界：在 TwinCAT 3 XAE 里是看不到非 TwinCAT 文件的历史版本的，想看就得切到 Git Bash。我最早图省事，把整份技术文档目录塞进 PLC 项目文件夹里一起管理，结果两边状态互相污染，花了半天才理清。从那以后我每次新建项目，第一件事就是把代码目录和文档目录在物理上分开，再分别接两套 Git，走一遍「改一处、提交一次、回 History 确认」的验证。这个习惯看着笨，但它替我省掉的返工时间，远多于它花掉的十分钟。希望帮到你。

本文还有配套的精品资源，点击获取