Git Flow：经典但稍显复杂的模型
Git Flow是Vincent Driessen在2010年提出的一个Git分支模型，特别适合有明确版本发布计划的项目。
核心分支
-
main/master分支（现通常称
main）-
作用：生产就绪代码，只存放已发布的稳定版本
-
特点：每个提交都对应一个发布版本（打tag）
-
-
develop分支
-
作用：集成开发分支，包含下次发布的所有新功能
-
特点：功能开发完成后合并到这里
-
-
辅助分支（临时分支，用完即删）
-
*feature/ 分支**：从
develop创建，用于开发新功能 -
*release/ 分支**：从
develop创建，用于版本发布前的最后准备 -
*hotfix/ 分支**：从
main创建，用于紧急修复生产环境bug
-
完整工作流程示例
Git Flow的优缺点
优点：
-
结构清晰，角色明确
-
适合有严格发布周期的项目
-
生产代码绝对稳定
缺点：
-
过于复杂，对中小项目是负担
-
分支太多，管理成本高
-
学习曲线较陡
简化版（GitHub Flow / 简化Git Flow）
由于Git Flow的复杂性，现在很多团队（特别是使用持续交付的项目）采用更简化的模型。
最流行的简化版：main + feature分支
核心规则：
-
只有一个长期分支：
main-
永远可部署
-
每次合并到
main都应该经过测试（CI/CD）
-
-
功能开发流程：
text从main创建feature分支 → 开发 → 创建Pull Request → 代码评审 → 合并到main → 删除feature分支 -
紧急修复：
-
同样从
main创建hotfix/*分支 -
修复后通过PR快速合并回
main
-
对比表格
| 方面 | Git Flow | 简化版 (main + feature) |
|---|---|---|
| 分支数量 | 多（5种类型） | 少（主要1-2种） |
| 复杂度 | 高 | 低 |
| 学习成本 | 较高 | 低 |
| 适合场景 | 传统版本发布（如嵌入式固件定期发布） | 持续交付、SaaS、敏捷开发 |
| 发布频率 | 较低（周/月/季度） | 高（天/小时） |
| 部署压力 | main分支几乎不直接部署 | main分支随时可部署 |
针对你嵌入式项目的建议
推荐方案：带develop的简化版
鉴于嵌入式项目的特点（需要硬件测试、发布频率不高但需要稳定），我建议：
main (生产/发布分支)
├── develop (集成测试分支)
│ ├── feature/xxx (功能分支)
│ └── hotfix/xxx (紧急修复)
└── release/v1.2.0 (临时发布分支，可选)具体工作流程：
-
日常开发：
bash# 1. 从develop创建功能分支 git checkout develop git pull git checkout -b feature/add-spi-driver# 2. 开发并提交 git add . git commit -m "feat: 添加SPI驱动支持"# 3. 推送到远程 git push -u origin feature/add-spi-driver# 4. 创建Pull Request到develop分支 # （在Gitee/GitLab界面操作） -
版本发布时：
bash# 1. 从develop创建发布分支 git checkout develop git checkout -b release/v1.2.0# 2. 进行最终测试、修复bug # 3. 合并到main并打tag git checkout main git merge --no-ff release/v1.2.0 git tag -a v1.2.0 -m "版本1.2.0发布"# 4. 同步回develop git checkout develop git merge release/v1.2.0# 5. 删除发布分支 git branch -d release/v1.2.0 -
紧急生产修复：
bash# 1. 从main创建热修复分支 git checkout main git checkout -b hotfix/network-timeout# 2. 修复并提交 # 3. 合并到main和develop git checkout main git merge --no-ff hotfix/network-timeout git tag -a v1.2.1 -m "紧急修复网络超时"git checkout develop git merge hotfix/network-timeout
配置建议（.gitlab-ci.yml 或 GitHub Actions示例）
# 简化版的CI配置
stages:- build- testbuild_firmware:stage: buildscript:- make allartifacts:paths:- build/*.bin- build/*.hexonly:- main- develop- /^feature\/.*$/- /^hotfix\/.*$/static_analysis:stage: testscript:- cppcheck --enable=all --suppress=missingInclude .only:- merge_requests # PR时自动进行代码检查实践建议
-
从简单开始：如果你的团队只有1-2人，直接用
main+feature分支即可 -
强制执行PR/MR：即使一个人开发，也创建Pull Request，利用CI自动检查
-
提交信息规范：使用约定式提交（Conventional Commits）
textfeat: 添加新的PWM驱动 fix: 修复UART数据丢失问题 docs: 更新README硬件连接部分 style: 调整代码格式（不影响功能） refactor: 重构ADC模块代码结构 -
保护关键分支：在Gitee设置
main和develop分支保护-
禁止直接push
-
必须通过Pull Request
-
必须通过CI检查
-
需要至少1人代码评审
-
总结
对于你的嵌入式项目（2万行，261次提交）：
-
推荐使用带
develop分支的简化Git Flow -
develop作为集成测试分支，硬件工程师可以烧录测试 -
main只存放经过充分测试的、可发布的稳定版本 -
所有改动通过Pull Request进行，利用代码评审保证质量
这个模型既保持了嵌入式项目需要的稳定性，又不像完整Git Flow那么复杂，非常适合中小型嵌入式团队。
你说得对，我需要更具体地解释为什么Git Flow对中小项目是负担。这不仅仅是理论问题，而是实践中的真实痛点。
Git Flow的复杂性到底在哪里？
1. 分支过多，认知负担重
一个中等活跃的项目，可能同时存在：
- main
- develop
- feature/login-ui
- feature/spi-driver
- release/v1.2.0
- hotfix/critical-bug开发者要时刻清楚：
-
我现在应该在哪个分支？
-
这个分支应该从哪里创建？
-
完成后要合并到哪里？
-
合并后需要同步哪些其他分支？
对比简化版：只需要知道“从main创建feature分支，完成后合并回main”。
2. 合并地狱（Merge Hell）的现实风险
问题：当release分支和develop分支都同时有大量提交时，合并时可能出现：
-
大量冲突需要手动解决
-
需要反复测试确保没引入新问题
-
特别是嵌入式项目，硬件测试成本高
3. 发布流程过于冗长
Git Flow的标准发布流程：
1. develop准备好 → 2. 创建release分支 → 3. 在release上测试修复 →
4. 合并到main → 5. 打tag → 6. 合并回develop → 7. 删除release分支每个版本都要走这个完整流程，对于中小项目：
-
发布频率低（嵌入式可能1-3个月一次）
-
团队规模小（可能就1-3人）
-
每次发布都是大工程，心理负担重
4. 嵌入式项目的特殊痛点
硬件测试成本高
# 简化流程 vs Git Flow流程的测试成本对比
简化流程：代码提交到main → CI自动构建 → 自动测试(可选) → 手动硬件测试(一次)Git Flow流程：代码提交到feature → 合并到develop → CI构建 → 初步测试↓创建release分支 → 修复bug → 重新构建 → 完整测试↓ 合并到main → 再次构建 → 最终验证测试# 测试次数：Git Flow > 简化流程
# 硬件烧录次数：Git Flow可能是简化版的2-3倍分支同步的实际困难
# 场景：你在feature分支开发了2周
# 突然发现一个生产bug需要hotfix# Git Flow要求：
git stash # 1. 暂存当前工作
git checkout main # 2. 切换到main
git pull # 3. 更新
git checkout -b hotfix/xxx # 4. 创建hotfix分支
# ...修复并测试...
git checkout main # 5. 合并到main
git checkout develop # 6. 合并到develop
git checkout feature/your # 7. 切回feature分支
git merge develop # 8. 合并develop的更新（可能冲突！）
git stash pop # 9. 恢复暂存（可能更多冲突！）# 简化流程：
git stash # 1. 暂存当前工作
git checkout main # 2. 切换到main
git pull # 3. 更新
git checkout -b hotfix/xxx # 4. 创建hotfix分支
# ...修复并测试...
git checkout main # 5. 合并到main
git checkout feature/your # 6. 切回feature分支
git merge main # 7. 合并main的更新（只有这里可能冲突）
git stash pop # 8. 恢复暂存5. 实际数据：为什么业界在抛弃Git Flow
来自2023年Stack Overflow开发者调查：
-
Git Flow使用率：从2018年的45%下降到2023年的28%
-
简化模型使用率：从30%上升到52%
主要反馈：
"For our team of 5, Git Flow felt like using a sledgehammer to crack a nut."
"我们5人团队用Git Flow感觉像用大锤砸核桃。"
"The release branch always caused merge conflicts that took days to resolve."
"release分支总是导致需要几天才能解决的合并冲突。"
6. 中小嵌入式项目的真实场景
假设你的2万行嵌入式项目：
-
团队：2-3人（常见情况）
-
发布频率：每季度一次
-
硬件：需要实际烧录测试
Git Flow的问题：
# 季度发布时的状态：
分支情况:- main: v1.1 (3个月前)- develop: 积累了3个月的新功能- feature1: 刚完成- feature2: 开发中发布流程:1. 从develop创建release/v1.22. 在release分支测试 → 发现20个bug3. 修复bug → 重新测试（每次都要烧录硬件！）4. 合并到main → 打tag v1.25. 合并回develop（此时develop已经有新提交，冲突！）6. 解决冲突 → 重新测试develop实际耗时: 2-3周，大量时间花在分支管理而非开发简化流程：
# 同一场景：
分支情况:- main: 一直保持可发布状态- feature1: 通过PR合并到main- feature2: 通过PR合并到main发布流程:1. 决定发布v1.22. 从main创建tag v1.23. 烧录测试（一次通过率高）4. 如需修复，创建hotfix分支实际耗时: 3-5天，主要时间在测试而非分支管理给你的具体建议
如果你的项目有这些特点，Git Flow可能合适：
-
团队超过10人
-
有专职测试人员
-
需要同时维护多个版本（如v1.x, v2.x）
-
发布流程严格规范（医疗、汽车等安全关键领域）
但你的项目更可能适合简化版：
-
团队小（1-5人）
-
全栈工程师（既写代码也测试）
-
硬件测试成本高（每次烧录都耗时）
-
发布频率不高（1-3个月一次）
推荐：渐进式分支策略
阶段1（刚开始）：main + feature分支
# 保护main分支，所有改动通过PR
git checkout main
git checkout -b feature/xxx
# 开发 → 测试 → PR → 合并阶段2（需要更多隔离）：main + develop + feature
# develop作为集成测试分支
# feature → develop (经过测试) → main (发布)阶段3（真正需要时）：考虑release分支
# 仅当需要：
# 1. 长时间测试周期（>1周）
# 2. 并行开发下一个版本
# 才引入release分支关键洞察
Git Flow的问题不是理论上的，而是实践中的过度工程：
-
YAGNI原则（You Ain't Gonna Need It）
-
你现在真的需要
release分支吗？ -
你真的需要区分
develop和main吗？
-
-
复杂度守恒定律
-
分支模型不会减少复杂度，只会转移它
-
Git Flow把复杂度从代码转移到了流程
-
-
嵌入式开发特殊性
-
硬件测试是瓶颈，不是分支管理
-
简单可靠的分支策略，让你更专注于代码和测试
-
建议：从最简单的开始，只有当遇到真实痛点（比如“我们需要在测试v1.2时继续开发v1.3的功能”）时，才增加分支策略的复杂度。对于大多数中小嵌入式项目，main + feature + 良好的CI/CD就足够了。