一、版本管理基础：为什么剃须刀嵌入式软件需要版本管理？版本管理的核心概念（基线、标签、分支）
各位工程师，咱们直接切入正题。
剃须刀，听起来是个简单的产品对吧？刀头、马达、电池，完事。但你真正做过就知道，现在的智能剃须刀，里面跑的嵌入式软件，复杂度一点不比小家电差。我见过不少团队，一开始觉得“就一个剃须刀嘛，版本管理随便搞搞就行”，结果后面吃尽了苦头。
1.1 为什么剃须刀嵌入式软件需要版本管理？
说白了，版本管理就是给你的代码“上户口”。没有户口，你都不知道哪个版本在哪个产品里跑着。
第一个原因：硬件迭代太快。
我做过一个项目，剃须刀的马达从有刷换成了无刷，控制算法全得改。如果没有版本管理，你根本分不清手里的代码是适配老马达还是新马达的。我曾经在产线上看到过，烧录了旧版固件的剃须刀，新马达转起来嗡嗡响，刀头直接卡死。嗯，那批货全返工了。
第二个原因：客户定制需求多。
有的客户要“旅行锁”，有的要“电量百分比显示”，有的要“蓝牙连接APP”。你想想看，每个客户一个分支，没有版本管理，代码就成了一锅粥。我见过一个团队，用文件夹命名来区分版本，比如“最终版”、“最终版2”、“打死不改版”……结果呢？客户投诉说功能不对，他们查了三天才发现，发给产线的版本是“最终版”，但测试部测的是“最终版2”。
第三个原因：安全与合规。
剃须刀涉及锂电池充电管理，安全标准很严格。如果某个版本充电逻辑有bug，你得能快速定位是哪个版本、哪个提交引入的问题。没有版本管理，你连回溯都做不到。
核心观点：版本管理不是“锦上添花”，而是“保命工具”。它让你知道“谁、在什么时候、为什么、改了什么东西”。
1.2 版本管理的核心概念
好，咱们来聊聊三个最基础的概念：基线、标签、分支。我习惯把它们比作“锚点”、“里程碑”和“平行宇宙”。
1.2.1 基线（Baseline）
基线是什么？就是“一个经过评审、可以信赖的稳定版本”。
在剃须刀嵌入式软件里，基线通常对应一个“发布给测试部”或者“发布给产线”的版本。比如，你完成了充电管理模块、电机控制模块、UI显示模块的联调，所有功能都通过了内部自测，这时候就可以打一个基线。
我在项目中遇到过这样的情况：开发人员觉得“基线嘛，随时可以打”，结果基线打得太多太乱，反而失去了参考意义。我的建议是：基线不要频繁打，但打了就要严肃对待。一般一个迭代周期（比如两周）打一次基线就够了。
个人技巧：我习惯在基线名称里加上“硬件版本号”，比如“baseline_v1.2_hw_revB”。这样一看就知道这个基线适配的是哪个硬件版本，避免搞混。
1.2.2 标签（Tag）
标签，说白了就是给某个提交（commit）贴一个“好记的名字”。它和基线很像，但更轻量。
标签通常用于标记“发布版本”。比如你给产线发了一个固件，版本号是“v2.0.1”，你就可以在Git里打一个标签叫“release_v2.0.1”。这样以后想回退到这个版本，直接找标签就行，不用去翻那一长串的commit hash。
我曾经犯过一个错误：标签打得太随意，比如“test”、“fix”、“temp”这种。结果过了一个月，我自己都分不清哪个标签对应哪个版本。后来我定了个规矩：标签命名必须包含版本号和日期，比如“v2.0.1_20250315”。
注意：标签一旦打了，尽量不要删除或修改。它应该是一个“只读”的标记。如果你需要修改，那就打一个新的标签。
1.2.3 分支（Branch）
分支，是版本管理里最强大的功能，也是最容易搞乱的地方。
分支让你可以在“平行宇宙”里开发，互不干扰。比如，你正在开发“蓝牙连接”功能，但突然产线说有个紧急bug要修。你怎么办？如果没有分支，你只能把蓝牙代码先注释掉，修完bug再恢复。有了分支，你只需要切到“master”分支，修bug，合并回去，完事。
我建议的剃须刀嵌入式软件分支策略是这样的：
- master分支：只放经过测试、可以发布的稳定代码。任何人不能直接往master上提交代码。
- develop分支：日常开发的主分支。所有新功能都在这里集成。
- feature分支：每个新功能一个分支，比如“feature_bluetooth”、“feature_travel_lock”。开发完成后合并到develop。
- hotfix分支：用于紧急修复产线bug。从master拉出来，修完合并回master和develop。
你想想看，如果没有分支，多个开发人员同时改同一个文件，冲突能让你改到怀疑人生。我记得有一次，两个同事同时改了电机控制的PWM参数，一个改的是加速曲线，一个改的是减速曲线。没有分支管理，他们俩的代码直接覆盖了对方，结果电机转起来一顿一顿的。后来用了分支，各自在feature分支上开发，最后合并时仔细处理冲突，再也没出过这种问题。
避坑指南：分支不是越多越好。我见过一个项目，分支开了几十个，最后没人记得哪个分支是干嘛的。我的经验是：分支的生命周期要短，功能开发完就合并删除，不要留着过年。
1.3 三者之间的关系
基线、标签、分支，它们不是孤立的。我习惯这样用：
- 分支是开发的主战场，你在上面写代码、改bug。
- 基线是分支上的一个“稳定快照”，通常对应一个重要的里程碑（比如测试版本）。
- 标签是基线或发布版本的“名字”，方便你快速找到它。
举个例子：你在develop分支上开发，完成了充电管理模块的联调，这时候打一个基线“baseline_charge_v1.0”。然后测试部测完了，没问题，你把这个基线发布给产线，再打一个标签“release_v1.0”。以后产线说“v1.0版本有问题”，你直接找标签“release_v1.0”就能定位到代码。
我的习惯：每次打基线时，顺手打一个同名的标签。这样基线可以随着开发继续推进，而标签永远指向那个历史版本，不会变。
1.4 总结
版本管理，说白了就是让你的代码“有迹可循”。没有它，你就是在裸奔。我做了这么多年嵌入式，见过太多因为没有版本管理而翻车的项目。剃须刀虽然小，但代码逻辑一点不简单。从今天开始，给你的代码上户口吧。
下一章，咱们聊聊具体的版本号命名规范，以及如何用Git管理剃须刀嵌入式软件。到时候我会分享一些我踩过的坑，保证让你少走弯路。