git 和气体探测，体探这两个词放一块儿，体探乍看像是体探程序员和消防员在鸡同鸭讲。但你要是体探真在工业现场蹲过几天，就会明白它们其实是体探一对儿——一个管代码的版本，一个管空气的体探版本。

我见过最离谱的体探一次泄漏事故，不是体探设备坏了，是体探“人觉得它没坏”。那天巡检员拿着老式催化燃烧式探测器，体探数值跳了几下，体探他拍了拍外壳，体探认定是体探风把食堂油烟吹过来了。结果半小时后，体探控制室报警器像疯了一样叫，体探整条生产线紧急停车。事后复盘，传感器早该校准了，但没人记得上次校准是什么时候——记录本上那栏空白得像刚擦过的白板。

气体探测的本质，是追踪变化。可变化这东西，最怕的就是“没有记录”。你这次校准了，下次呢？你换了传感器，旧的数据归档了吗？今天这个报警阈值是谁调的？为什么调？如果这些问题答不上来，那你的安全系统就跟没装一样。

Git 干的就是这个活儿。它不生产气体，也不检测浓度，它管的是“谁在什么时候改了什么”。把传感器的校准记录、报警阈值调整、固件升级、甚至误报日志统统提交进仓库，每次改动都留下 commit——这才是真正的“可追溯”。

有个化工厂的朋友跟我讲，他们现在用 Git 管理所有探测器的配置文件。以前改个报警值，靠口头传达，或者发个 Excel 表格，版本乱得跟毛线团似的。现在好了，每次改动都走 pull request，得有另一个人 review 才能合并。他说这话时，眼神里带着一种“终于不用背锅”的释然。那种感觉，就像你终于把散落一地的螺丝钉，按大小分好了类。

但别以为上了 Git 就万事大吉。工具是死的，人是活的。你得把“提交信息”写得像人话，而不是“update”或者“fix”。我见过有人把校准记录写成“改了”，三个月后自己都看不懂改了什么。这跟没写有什么区别？Git 不是保险箱，它是一面镜子——你给它什么，它照出什么。

还有个细节，容易被忽视。探测器的生命周期，从出厂到报废，中间可能换过三次传感器、两次主板。这些硬件变更，如果只记在纸质台账上，那跟没记一样。但要是把硬件序列号、更换日期、新传感器的响应系数全写进 Git 的 tag 里，那这台设备的“一生”就清清楚楚了。哪天出问题，翻一下历史，立刻能定位是哪个环节埋的雷。

说白了，气体探测管的是“现在空气中有什么”，Git 管的是“过去我们做了什么”。两者结合，你才有底气回答那个最要命的问题：“如果今天出事，你知道为什么吗？”

别等到爆炸声响起，才想起来查记录。那时候，Git 也救不了你——它只能告诉你，你早就该改，但没改。