必须用 hotfix/ 分支修复线上故障，因其确保最小变更、最快上线、可回滚；须从 main 拉取以保证代码稳定可信，命名含问题标识，修复后同步合并至 main 和 develop，并打带补丁标识的 tag。
线上故障必须立刻修复，但当前开发分支有大量未完成代码 —— 此时不能直接在 main 上改，也不能把脏代码一起合进去。唯一安全、可追溯、不影响其他人的做法，是用 hotfix/ 临时分支。
为什么必须从 main 拉 hotfix/ 分支
线上故障修复的核心前提是「最小变更 + 最快上线 + 可回滚」。如果从 develop 或某个 feature/ 分支拉修复分支，会把尚未测试、甚至编译不过的代码一并带入生产环境，风险极高。
-
main分支始终代表已验证、可部署的稳定状态，是唯一可信的修复起点 - 所有
hotfix/分支命名必须带问题标识，例如hotfix/uart-rx-overflow-#204，方便后续定位和审计 - 修复完成后，必须同时合并回
main和develop：前者保证线上立即生效，后者防止同类问题在开发中重复出现
git checkout -b hotfix/xxx main 后要立刻做的事
拉完分支只是开始。C 项目（尤其嵌入式）对构建链路、硬件适配、版本号一致性极其敏感，漏掉任何一步都可能导致烧录失败或行为异常。
- 立即修改
VERSION或build_info.h中的补丁号（如v1.3.2-p1），避免和正式发布版本混淆 - 只改故障相关文件，禁止顺手优化、重构、加日志——这些留到
develop阶段做 - 本地完整编译 + 硬件实机验证通过后，再推送分支：
git push origin hotfix/uart-rx-overflow-#204 - 触发 CI 流水线时，确保它走的是「紧急通道」：跳过耗时的静态分析、覆盖率检查，但保留基础编译、链接、裸机启动测试
合并 hotfix 到 main 和 develop 的顺序与参数
顺序错了，develop 就会丢失这次修复；参数错了，历史会变得难以追踪，Git 工具也容易误判冲突来源。
- 先切到
main：git checkout main，再合并：git merge --no-ff hotfix/uart-rx-overflow-#204（--no-ff强制生成合并提交，保留分支上下文） - 打 tag：
git tag -a v1.3.2-p1 -m "Fix UART RX overflow (issue #204)"，tag 名必须含补丁标识 - 再切到
develop：git checkout develop，同样用--no-ff合并：git merge --no-ff hotfix/uart-rx-overflow-#204 - 最后删掉临时分支：
git branch -d hotfix/uart-rx-overflow-#204（本地），git push origin --delete hotfix/uart-rx-overflow-#204（远程）
最容易被忽略的 C 项目特有问题
Java 或 Web 项目出错还能热更新、重启服务，C 项目（尤其固件）一旦烧录错误，设备可能变砖。很多团队卡在这一步不是不会操作 Git，而是没意识到底层约束。
- 修复代码里如果有宏定义变更（比如
#define MAX_RX_BUF 512→1024），必须确认 linker script 是否预留足够 RAM，否则链接通过但运行崩溃 - 中断服务函数（ISR）内新增逻辑，必须检查是否引入不可重入操作或超时 —— 这类问题不会在单元测试里暴露，只会在真实负载下复现
-
hotfix分支上禁止使用git rebase整理提交，因为main和develop同时合并时，rebase 会导致两个分支看到不同 SHA，引发后续合并混乱
