硬件固件开发中，develop 分支该怎么管？

做嵌入式硬件维护的兄弟们，常遇到这种情况：新功能刚加进固件，测试还没跑完，客户现场又急着要一个紧急 bug 修复。这时候，git 上 develop 分支一乱，版本就分不清了，烧录错固件，板子直接变砖——我上个月就在客户机房蹲了俩小时重刷 bootloader。

develop 不是“随便改”的分支

很多团队把 develop 当成“日常开发主干”，谁想改就 push，结果 merge 冲突天天见，CI 构建频繁失败。其实 develop 应该是“稳定可构建”的快照：它不一定包含所有新特性，但必须能编译、能烧写、能通过基础自检（比如 UART 初始化成功、ADC 读数在合理范围）。

一个接地气的分支流程

我们组现在用这套轻量规则，没加任何复杂工具，靠约定就能跑顺：

• 所有功能开发从 develop 拉出 feature/xxx 分支，命名带硬件模块名，比如 feature/pwm-freq-extend；
• feature 分支合入前，必须在目标硬件（比如 STM32H743 最小系统板）上实测通过基本功能；
• 合入 develop 后，立刻打 tag：v20240521-develop（日期+分支名），方便回溯；
• 紧急现场 patch，从最近一次 tag 拉 hotfix 分支，修完先在同型号旧板上验证，再合入 develop 和 release 分支。

别忘了硬件的“不可逆性”

软件 rebase 还能救，硬件烧坏的 Flash 就真坏了。所以 develop 分支每次更新，建议同步更新 hw-compat.md 文档，写清本次变更影响的硬件型号、最小供电电压变化、是否需要重新校准传感器。上次我们升级 SPI 驱动，忘了标“需重烧 EEPROM 中的时钟配置”，三台 AGV 小车集体丢编码器信号，排查两天。

一个小脚本帮你盯住 develop

每天下班前跑一遍，省心：

#!/bin/bash
# check-develop.sh
if git diff --quiet origin/develop; then
  echo "develop 无新提交"
else
  echo "⚠️ develop 有更新：$(git log -1 --oneline origin/develop)"
  # 自动触发硬件回归测试任务（调用 Jenkins API 或本地串口测试脚本）
fi

develop 分支不是仓库里最热闹的那个，而是最让人放心的那个——它背后连着的是你亲手调过的那块 PCB，和客户机柜里正在跑的设备。