4. Git基础操作
说到分支管理，很多团队一开始都觉得「不就是建几个分支嘛，有啥好纠结的」。但我在嵌入式项目里栽过跟头之后，才真正明白——选错分支模型，比没有版本控制更痛苦。
你想想看，嵌入式项目有它的特殊性：硬件依赖、固件版本、BSP 包管理、多平台适配……这些都不是纯软件项目能比的。今天我们就来聊聊三种主流分支策略，看看它们到底适不适合嵌入式开发。
三种主流分支模型概览
先给个全景图，让你心里有个底。
| 模型 | 核心思想 | 分支数量 | 适合场景 |
|---|---|---|---|
| Git Flow | 严格的分支角色，长期分支 + 短期分支 | 多（5+ 种） | 有固定发布周期的产品 |
| GitHub Flow | 极简，只有 main + feature 分支 | 少（2 种） | 持续部署的 Web 项目 |
| GitLab Flow | 环境分支 + 功能分支，灵活适配 | 中（3~4 种） | 有环境隔离需求的项目 |
说白了，没有银弹。每种模型都有自己的脾气，关键看你的项目能不能「伺候」得了它。
Git Flow：经典但沉重
Git Flow 是我最早接触的分支模型。它把分支分成了 main、develop、feature、release、hotfix 五种角色。听起来很完备，对吧？
但我在一个车载项目里用过之后，发现它有个致命问题——合并成本太高。
嵌入式项目经常要维护多个硬件平台，每个平台可能有不同的 BSP 版本。如果用 Git Flow，每次从 develop 合并到 release，都要解决一堆冲突。尤其是底层驱动代码，改一行可能影响整个板级包。
我的经验：Git Flow 适合那种「发布节奏固定、硬件平台单一」的项目。比如消费电子产品的固件，每两个月发一个版本，用 Git Flow 很稳。但如果你的项目有 5 个以上的硬件变体，我建议你慎重。
嵌入式适配建议
- 保留
develop分支：作为日常集成的基线，所有 feature 分支从它拉出 - 为每个硬件平台建
release/xxx：比如release/v2.1-stm32、release/v2.1-esp32 - hotfix 分支直接修
main：修完立刻合并回develop和当前release - 避免在
develop上直接提交：所有改动走 feature 分支 + PR
我曾经踩过的坑：有一次在 develop 上直接改了个 I2C 驱动的时序参数，结果另一个同事也在改同一文件。合并时才发现冲突，但已经影响到三个 feature 分支的 CI 构建。从那以后，我强制团队所有改动必须走 feature 分支。
GitHub Flow：极简但不够用
GitHub Flow 的理念是「简单到极致」。只有 main 分支，所有功能从 main 拉出，开发完合并回去，然后立刻部署。
听起来很爽，对吧？但嵌入式项目很少能这么干。
为什么？因为嵌入式项目有「硬件依赖」和「烧录验证」这两个硬门槛。你不能像 Web 项目那样，合并完代码就自动部署到生产环境。你得烧录、上电、跑测试、看波形……这一套流程下来，少说也得半小时。
我的建议：GitHub Flow 只适合嵌入式项目中的「工具链脚本」或「测试用例」仓库。这些代码不依赖硬件，改完就能跑 CI。但如果是固件仓库，别用 GitHub Flow，你会后悔的。
什么时候可以用？
- 纯 Python 或 Shell 脚本的工具仓库
- 自动化测试用例仓库（不依赖硬件）
- 文档仓库（比如 API 手册、用户指南）
- 内部使用的 CI/CD 配置仓库
GitLab Flow：嵌入式项目的折中方案
我个人最推荐嵌入式团队用 GitLab Flow。为什么？因为它够灵活。
GitLab Flow 的核心思想是「环境分支」。你可以为不同的部署环境建分支，比如 staging、production。每个环境分支对应一个验证阶段。
在嵌入式项目里，我们可以把这个思路改一改：
main：稳定发布版，只接受经过完整验证的代码develop：日常集成，所有 feature 分支合并到这里hw-xxx：硬件平台分支，比如hw-stm32f4、hw-esp32s3release/vX.Y：发布候选分支，用于最终验证
你看，GitLab Flow 允许你根据项目需要「定制」分支策略，而不是被模型框死。
我的实践：在一个物联网网关项目里，我们用 GitLab Flow 管理了 4 个硬件平台。每个平台有自己的 hw-xxx 分支，公共代码在 develop 上维护。平台特有的驱动和配置放在各自分支里。这样既保证了代码复用，又避免了平台间的冲突。
嵌入式项目的分支策略选择矩阵
我整理了一个选择矩阵，帮你快速判断该用哪种模型。
| 项目特征 | 推荐模型 | 理由 |
|---|---|---|
| 单一硬件平台，固定发布周期 | Git Flow | 分支角色清晰，适合长周期开发 |
| 多硬件平台，持续集成 | GitLab Flow | 环境分支灵活，平台隔离性好 |
| 纯工具/脚本仓库 | GitHub Flow | 极简，快速迭代 |
| 原型验证阶段 | GitHub Flow | 不需要复杂分支，快速出结果 |
| 车规/工控等高可靠性项目 | Git Flow + 定制 | 严格的发布流程，hotfix 机制完善 |
| 开源嵌入式项目 | GitHub Flow | 社区习惯，PR 流程简单 |
嵌入式项目分支适配的关键点
不管你选哪种模型，有几个点一定要处理好：
- 硬件平台分支必须长期维护：不要合并回主分支就删掉，嵌入式项目经常要回退到某个硬件版本
- BSP 包单独管理：BSP 最好用子模块或独立仓库，不要和业务代码混在一个分支里
- CI 触发策略要精细：不是所有分支都跑完整 CI。比如
hw-xxx分支只跑对应平台的编译和单元测试 - 发布标签要包含硬件信息：比如
v2.1.0-stm32f4，方便追溯
我曾经踩过的坑：有一次把 BSP 包直接放在 develop 分支里，结果一个同事更新了 STM32 的 HAL 库，另一个同事更新了 ESP32 的 SDK。合并时发现两个 BSP 版本不兼容，整个项目编译失败。后来我把 BSP 拆成子模块，每个平台独立管理，再也没出过这种问题。
SVG：分支策略选择决策图
下面这张图帮你理清选择思路。从项目类型出发，一步步找到适合你的分支模型。
总结一下
分支管理没有标准答案。我见过用 Git Flow 跑得很顺的嵌入式团队，也见过被 GitHub Flow 坑惨的。关键是你得理解每种模型的「设计哲学」，然后根据项目实际情况做适配。
我个人建议：从 GitLab Flow 开始。它足够灵活，能应对大多数嵌入式项目的需求。等团队成熟了，再根据实际情况调整。
记住一点：分支策略是为开发流程服务的，不是反过来。别让分支模型绑架了你的团队。