📚 课程目录第3章源代码控制基础与LabVIEW集成

3. 源代码控制基础与LabVIEW集成

LabVIEW 的源代码控制与纯文本语言有本质差异：VI 是二进制容器，前面板、程序框图、连线数据、编译代码都封装在同一个 .vi 文件里。若直接把整个 VI 交给 Git，Git 只能判断“文件变了”，无法告诉你“哪根线被移动了”。因此，LabVIEW 与 Git 的集成重点不是“能不能提交”，而是如何让差异可读、合并可做、历史可追溯。本节围绕 Git 核心概念、集成配置、忽略与属性设置、提交与分支策略四部分展开。

一、Git 核心概念在 LabVIEW 语境下的映射

Git 的四个区域——工作区、暂存区、本地仓库、远程仓库——在 LabVIEW 项目中对应不同的操作对象。工作区是你正在编辑的 VI、控件、项目文件；暂存区是 git add 后准备提交的快照；本地仓库保存每次提交的历史；远程仓库用于团队共享。理解这一点，才能解释为什么“改了 VI 但没 add”不会进入提交。

三个关键概念需要特别说明。提交（commit）是一次不可变的快照，包含作者、时间、父提交和变更内容；分支（branch）是指向某次提交的可移动指针，用于隔离开发线；合并（merge）是把两条分支的历史重新汇合。对 LabVIEW 而言，合并的难点在于 VI 是二进制，Git 默认无法做行级合并，必须借助外部比较工具或文本化格式。

另一个必须建立的概念是“文本化”。LabVIEW 从 2013 起支持将 VI 保存为文本格式（通过“工具 → 选项 → 环境 → 将新 VI 保存为文本”或项目级设置），使 VI 内部结构以可读文本存储。文本化后，Git 才能对 VI 做有意义的 diff 和 merge。这是 LabVIEW 与 Git 集成的前提性配置，不是可选项。

二、LabVIEW 与 Git 集成配置

集成配置分三步。第一步，在 LabVIEW 中启用文本化保存：进入“工具 → 选项 → 环境”，勾选“将新 VI 保存为文本”，或在项目属性中为现有 VI 设置“保存为文本”。第二步，配置 Git 的差异与合并工具。在 .gitconfig 或仓库级配置中指定 LabVIEW 自带的比较工具，例如：

[diff "labview"]
    command = "C:/Program Files/National Instruments/LabVIEW 2023/labviewcompare.exe"
[merge "labview"]
    name = LabVIEW merge driver
    driver = "C:/Program Files/National Instruments/LabVIEW 2023/labviewmerge.exe" %O %A %B

第三步，在仓库根目录放置 .gitattributes，把 VI 相关文件绑定到上述驱动。这样 git diff 和 git merge 遇到 VI 时会自动调用 LabVIEW 工具，而不是按二进制处理。

三、.gitignore 与 .gitattributes 设置

.gitignore 决定哪些文件不进入版本控制。LabVIEW 项目中必须忽略的是编译产物和临时文件，典型条目如下：

# LabVIEW 编译与临时文件
*.aliases
*.lvlps
*.lvproj.lvlps
*.vi~ 
*.ctl~
*.bak
# 构建输出
Builds/
# 系统文件
.DS_Store
Thumbs.db

注意不要忽略 .lvproj、.vi、.ctl、.lvlib 这些真正的源文件。忽略规则写错，会导致队友拉不到项目文件或控件。

.gitattributes 则负责“怎么处理”。对 LabVIEW 项目，核心是声明文本化 VI 的合并驱动，并统一换行符：

*.vi diff=labview merge=labview
*.ctl diff=labview merge=labview
*.lvproj text eol=lf
*.lvlib text eol=lf

这两份文件应随仓库一起提交，放在根目录，确保每位成员克隆后行为一致。

四、提交与分支策略

提交策略的核心是“小步、清晰、可回退”。一次提交只做一件事：修一个 Bug、加一个功能点、改一处配置。提交信息建议采用“类型: 简述”格式，例如 fix: 修正压力采集通道量程换算、feat: 增加温度补偿子 VI。这样在 git log 中能快速定位。

分支策略推荐轻量级 Git Flow 变体：main 分支始终保持可发布状态；每个功能或修复从 main 切出 feature/xxx 或 fix/xxx 分支；完成后通过合并请求（Merge Request）合回 main。合并前先 git pull --rebase 拉取最新 main，减少冲突。对于测试系统部署，建议为每个发布版本打标签，如 v1.2.0，便于现场回滚。

实操建议：在团队中先统一 LabVIEW 版本与文本化设置，再统一 .gitattributes 与比较工具路径。三者不一致时，diff 结果会因机器而异，合并冲突会显著增加。

常见误区：把整个 Builds/ 目录提交进仓库，或忽略 .lvproj。前者让仓库迅速膨胀，后者让队友无法打开项目。提交前用 git status 确认待提交清单，是成本最低的防线。

把以上四部分串起来：文本化让 VI 可读，.gitattributes 让 Git 调用正确工具，.gitignore 挡住噪声，提交与分支策略保证历史清晰。四者缺一，LabVIEW 的版本管理就会退化成“只能存、不能比、不敢合”的二进制仓库。