3. 版本管理核心概念
在PLC软件开发中，一个项目往往包含梯形图、功能块、硬件组态、HMI画面、通信配置等多类文件。若没有统一的版本管理术语体系，团队成员对“当前用的是哪一版”“改动是否已提交”“能否安全合并”就会产生歧义。Git 提供了一套精确的概念模型，理解这些术语是后续所有操作的基础。
一、从工作区到仓库：三个区域的流转
Git 将文件状态划分为三个逻辑区域：工作区、暂存区和仓库。工作区是你在电脑上实际编辑的目录，PLC 工程文件、变量表、注释文档都放在这里；暂存区是一个中间缓冲区，用于挑选“本次要提交哪些改动”；仓库则保存所有已提交的历史快照。
文件从工作区到仓库，需要经过“暂存”和“提交”两个动作。暂存区让提交具备选择性：你可以只提交某个功能块的修改，而把调试用的临时变量留在工作区。对于 PLC 项目，这种选择性非常重要，因为一次提交最好只对应一个逻辑变更，例如“增加电机过载保护逻辑”，而不是把硬件组态、HMI 画面和通信参数混在一起。
# 查看当前状态：工作区、暂存区、仓库的差异
git status
# 将指定文件加入暂存区
git add PLC_Program/Main.st
git add Config/Hardware.xml
# 提交暂存区内容，形成一个新的版本快照
git commit -m "增加电机过载保护逻辑"
# 查看提交历史
git log --oneline --graph二、版本、提交与基线
版本在 Git 中通常指一次提交（commit），它由唯一的 SHA-1 哈希值标识，例如 a3f9c21。每个版本包含作者、时间、提交说明、父提交指针以及完整的文件快照。PLC 项目中的“版本”可以对应一次程序下载前的稳定状态，也可以对应一次现场调试后的参数调整。
基线是一个被正式确认、后续变更需受控的版本。它通常不是 Git 的内置命令，而是团队约定：例如“通过厂内测试并归档的提交”打上基线标记。基线的作用是提供可追溯的参照点，当现场出现问题时，可以快速回到基线版本进行对比。基线可以是某个提交，也可以是某个标签。
| 术语 | 本质 | PLC项目中的典型含义 | 是否可变 |
|---|---|---|---|
| 工作区 | 本地文件目录 | 正在编辑的梯形图、变量表、HMI画面 | 随时可变 |
| 暂存区 | 待提交快照的索引 | 本次准备提交的功能块与配置 | 可增删 |
| 版本/提交 | 完整快照+元数据 | 一次逻辑变更的存档 | 不可变 |
| 基线 | 受控的参照版本 | 通过测试并归档的稳定版本 | 只读参照 |
| 分支 | 指向提交的可移动指针 | 并行开发新功能或现场补丁 | 可移动 |
| 标签 | 指向提交的固定指针 | V1.0、V1.1、现场发布版 | 固定不变 |
| 仓库 | 提交历史的集合 | 本地或远程的完整项目历史 | 持续增长 |
三、分支、合并与冲突
分支是一条独立的开发线。Git 的分支本质上只是一个指向某个提交的指针，创建和切换成本极低。在 PLC 项目中，常见分支策略包括：main 保存稳定版本，feature/pid-tuning 开发 PID 参数整定功能，hotfix/io-mapping 处理现场 I/O 映射错误。分支让不同工程师可以并行工作，而不会互相覆盖。
合并是把一条分支的变更整合到另一条分支。Git 会尝试自动合并不同分支上的修改；如果两个分支修改了同一文件的同一区域，就会产生冲突。冲突不是错误，而是 Git 无法自动判断“应该保留哪一个”时，要求人工决策。PLC 项目中的冲突常出现在变量表、硬件组态和通信配置文件中，因为这些文件往往被多人同时修改。
# 创建并切换到新分支
git switch -c feature/pid-tuning
# 完成开发后切回主分支并合并
git switch main
git merge feature/pid-tuning
# 若出现冲突，查看冲突文件
git status
# 手动编辑冲突标记 <<<<<<< ======= >>>>>>>
# 解决后标记为已解决
git add PLC_Program/PID.st
git commit -m "合并PID整定功能并解决变量表冲突"四、标签与仓库
标签是给某个提交起的固定名字，常用于标记发布版本。与分支不同，标签不会移动。PLC 项目交付时，通常会在对应提交上打标签，例如 V1.0.0、V1.1.0-现场调试。标签让“现场设备上运行的是哪一版程序”这个问题有明确答案。
仓库是提交历史的集合，分为本地仓库和远程仓库。本地仓库位于工程师电脑上，包含完整历史；远程仓库通常部署在服务器或代码托管平台，用于团队共享和备份。PLC 项目文件体积可能较大，建议配置 .gitignore 排除编译中间文件、备份文件和临时日志，只保留源程序、组态和文档。
# 创建附注标签
git tag -a V1.0.0 -m "首版发布：包含主控逻辑与安全回路"
# 查看标签
git tag -l
# 添加远程仓库并推送
git remote add origin git@example.com:plc-team/project.git
git push -u origin main --tags五、案例场景：一次现场补丁的完整流转
假设现场反馈“传送带启动时偶尔抖动”。工程师首先从 main 的 V1.1.0 标签创建 hotfix/conveyor-jitter 分支，在工作区修改启动斜坡参数，git add 暂存修改，提交为“调整传送带启动斜坡时间”。测试通过后，将该分支合并回 main，解决与同事新增的报警逻辑之间的冲突，最后打上 V1.1.1 标签并推送到远程仓库。整个过程清晰可追溯：工作区改动、暂存区筛选、提交形成版本、分支隔离风险、合并整合成果、标签标记发布、仓库保存历史。
main 上直接做实验性修改；用“最终版”“最终版2”命名文件而不是使用标签；冲突时直接删除对方代码而不沟通。这些做法会破坏版本历史的可信度，导致现场问题难以定位。
六、术语关系总览
下图把本节核心术语放在同一条数据流上：工作区经过暂存区形成提交，提交汇入仓库并构成分支；分支可以合并，合并可能产生冲突；标签固定在某个提交上，基线则是被团队正式确认的参照版本。
掌握这些术语后，后续的 git status、git add、git commit、git branch、git merge、git tag 就不再是孤立命令，而是同一套快照模型下的不同操作。对 PLC 工程师而言，版本管理不是额外负担，而是让程序变更可追溯、可回退、可协作的基本工程能力。