一次提交打一个可运行标签（2026）

项目里改代码最常见的乱象：改了几十行，只有最终版能跑，中间版本全堆在文件夹里，文件名带“最终版2”“改完别动”。在传感器分析脚本上尤其明显，数据采集、清洗、特征计算、可视化每一步都可能改错。需要的不是一次性把整个流程写完，而是每完成一个能跑的功能，就提交一个可运行标签。

标签命名：日期加功能，一眼知道能做什么

以传感器分析脚本为例，项目里有一份温度湿度数据文件（示意：共1200条记录）。最初写了一个读取脚本，能打开文件并打印前5行。这个版本简单但能独立运行，值得打标签。

标签命名规则：日期（示意：20260115）+功能词（示意：read-data），完整标签名写作“20260115-read-data”。提交时用git tag，或在文件系统里创建同名文件夹存放该版本完整代码。关键是标签对应一个能跑通的入口，比如命令行写 python analyze.py --read，或点击一个run.bat。

下一个迭代加入数据清洗，去除明显错误值，新标签“20260116-clean-data”，入口 python analyze.py --clean。再加入滑动平均计算，标签“20260117-average”，入口 python analyze.py --average。每次只增加一个功能，不要在同一次提交里同时改读取方式又加清洗逻辑。

好处在于：如果“20260117-average”运行出错，可切回“20260116-clean-data”对比两版代码找出问题行。一次提交混了三个改动，出错后逐行排查耗时是分层次的（示意：混改排查约30分钟，单功能排查约5分钟）。

提交前三勾：能跑、入口清、半成品不打标

每次提交可运行标签前做三个确认，防止把半成品当成品提交。

1. 能跑：在干净目录里执行入口命令，不依赖当前环境的临时文件或调试变量。比如脚本里有个变量 temp_offset 在上一版调试时手动设了值，这一版没初始化，直接运行会报错。确认入口命令从零开始执行，得到预期输出（示意：输出1200行处理后的数据）。

2. 入口清：明确标注标签入口是命令行参数、双击脚本还是调用函数。在标签对应说明文件里写一行字，例如“运行入口：python analyze.py --average”。入口不止一个时列出所有可运行方式。默认别人知道怎么跑是不现实的，一个月后的自己也会忘记。

3. 半成品不打标：没有跑通的功能，或只有部分代码但缺少数据预处理步骤的版本都不打标签。哪怕觉得功能只差一两行就能跑完也不打。半成品标签会破坏标签可信度，下次找版本时误以为能用，反而浪费时间。一个标签必须对应完整可运行的流程，哪怕流程很短。

三勾顺序不能乱：先确认能跑，再确认入口清楚，然后确认不是半成品。打了半成品标签，入口再清晰也没用；入口不清但能跑，至少还能自己摸索。

一个贯穿的完整例子

传感器数据文件（示意：60分钟温湿度记录，每10秒一条，共360条）。步骤甲写读取脚本，打印每条记录时间、温度、湿度。打标签“20260115-read”，入口 python sensor.py --read。

步骤乙异常值过滤：温度大于50度或小于-10度的记录（示意：共3条异常）被剔除。打标签“20260116-filter”，入口 python sensor.py --filter。

步骤丙计算每分钟平均值，标签“20260117-minavg”，入口 python sensor.py --minavg。

步骤丁输出图表，标签“20260118-plot”，入口 python sensor.py --plot。

每一步只改一个功能。第四步做图时需调整数据格式，不直接改步骤丁，而是回退到前一可运行版修改数据输出结构，再打新标签“20260118-plot-v2”。原始前一版和修改版都保留。

标签多不代表混乱，反而证明迭代可追溯。用 git tag 可查看版本列表。每个标签对应一条可运行命令。

下一步：动手做首个标签

打开传感器分析脚本，找到当前能运行的版本。没有就先写最简版本：读取文件并打印一行。按命名规则打标签。用git则运行 git tag 20260115-read；没有git就在项目文件夹下新建“20260115-read”子文件夹，复制当前版本脚本和入口说明进去。

想一个下一步要加的功能（示意：计算每日平均温度），用三勾确认后提交下一标签。不急着写后续所有功能。先完成两个可运行标签，感受每次只改一个功能的清爽感，之前半成品堆叠的问题会自然消失。