3、版本控制入门：Git基础操作、分支管理策略、与团队协作的常见工作流
版本控制这东西，说白了就是给代码装了个「后悔药」和「时光机」。我见过不少新手，刚开始觉得 Git 麻烦，结果改崩了代码只能干瞪眼。嗯，咱们今天就把 Git 的基础操作、分支策略和团队协作工作流捋一遍。
3.1 Git 基础操作：三板斧
Git 的核心操作其实就三个动作：记录快照、切换版本、同步远程。我个人习惯把本地仓库分成三个区：工作区、暂存区、版本库。
| 区域 | 作用 | 常用命令 |
|---|---|---|
| 工作区 | 你写代码的地方，文件实际存在的位置 | git status、git diff |
| 暂存区 | 临时存放你准备提交的改动 | git add |
| 版本库 | 保存所有历史提交记录的地方 | git commit、git log |
核心流程：git add → git commit → git push
举个例子，你改了一个驱动文件 spi_driver.c：
# 查看当前状态
git status
# 把文件加入暂存区
git add spi_driver.c
# 提交到本地版本库
git commit -m "fix: 修复 SPI 时钟极性配置错误"
# 推送到远程仓库
git push origin main这里有个坑——提交信息一定要写清楚。我曾经在项目里看到过「update」「fix bug」这种提交信息，回头查问题的时候根本不知道改了啥。建议用 type: 描述 的格式，比如 feat: 添加 I2C 超时重试机制。
3.2 分支管理策略：别在主干上乱改
分支是 Git 最强大的功能之一。你想想看，如果没有分支，大家全在 main 上改代码，那画面太美不敢看。我建议团队至少维护三个长期分支：
- main：生产就绪代码，只允许合并，不允许直接提交
- develop：日常开发集成分支，所有功能分支从这里拉出
- release：预发布分支，用于测试和修复
分支操作其实就几个命令：
# 创建并切换到新分支
git checkout -b feature/add-watchdog
# 查看所有分支
git branch -a
# 合并分支
git checkout develop
git merge feature/add-watchdog
# 删除本地分支
git branch -d feature/add-watchdog注意：合并前一定要先 git pull 更新本地 develop，否则容易产生冲突。我曾经有一次忘了拉取，结果合并后冲突文件多达十几个，解了一下午。
3.3 团队协作的常见工作流
工作流说白了就是团队约定好的「代码流动规则」。我参与过的嵌入式项目里，最常用的是以下三种：
| 工作流 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Git Flow | 大型项目，有固定发布周期 | 分支职责清晰，适合多版本并行 | 分支多，管理成本高 |
| GitHub Flow | 持续交付，快速迭代 | 简单，只有 main 和 feature 分支 | 不适合多版本维护 |
| GitLab Flow | 需要环境分支（如 staging、production） | 与环境绑定，部署清晰 | 需要严格的权限控制 |
我个人比较推荐嵌入式团队用 Git Flow 的简化版。为什么？因为嵌入式项目通常有硬件依赖，固件版本和硬件版本需要对应，分支管理能帮你理清这些关系。
小技巧：在 feature 分支上开发时，每天至少 git pull --rebase 一次 develop 分支，减少最后合并时的冲突量。
3.4 核心流程可视化
下面这张图展示了 Git Flow 的核心流程，我建议你把它打印出来贴在工位上：
3.5 避坑指南
做嵌入式开发，Git 用得不好真的会出大问题。我总结几个常见坑：
- 不要提交编译产物：.o、.elf、.hex 这些文件不要进版本库，用
.gitignore过滤掉 - 大文件别用 Git：固件库、工具链压缩包用 Git LFS 或者单独管理
- 提交前先编译：我见过有人提交了编译不过的代码，整个团队卡了半天
- 合并冲突要冷静：用
git mergetool或者 IDE 的对比工具，别手动乱改
我曾经在合并时手抖删了一个关键的头文件，结果编译报错找了一上午。后来养成了习惯：合并前先 git stash 保存当前工作，合并完确认没问题再 pop 出来。
3.6 日常协作流程
一个典型的团队协作日是这样的：
- 早上：
git pull拉取最新 develop 代码 - 开发：从 develop 创建 feature 分支，开始写代码
- 提交：完成一个小功能就 commit，保持提交粒度适中
- 同步：每天至少 rebase 一次 develop，减少冲突
- 提 PR：功能开发完，在远程仓库创建 Pull Request
- Code Review：至少一个人 review 通过后才能合并
- 合并：用
--no-ff保留合并历史
小建议：PR 的描述要写清楚「改了啥」「为什么改」「怎么测试的」。我见过有人 PR 描述就写了个「fix bug」，reviewer 根本不知道从哪看起。
版本控制这事，刚开始觉得是负担，用顺手了就会发现它是开发效率的倍增器。记住一句话：频繁提交、及时同步、清晰描述，这三点做到了，团队协作基本不会出大问题。