🌐 Git Flow 简约图解
创建分支
创建分支
PR 合并
创建分支
PR 合并
PR 合并
紧急修复创建
PR 合并
PR 合并
main
主分支
生产环境
develop
开发基线
集成所有功能
feature/xxx
功能分支
开发新功能
release/xxx
发布分支
版本发布前测试与修复
hotfix/xxx
紧急修复分支
修复线上严重问题
🌐 优化后的Git Flow图解
增加了个人开发分支
创建分支
创建分支
PR 合并
创建分支
PR 合并
PR 合并
紧急修复创建
PR 合并
PR 合并
创建分支（本地）
PR 合并
main
主分支
生产环境
develop
开发基线
集成所有功能
feature/xxx
功能分支
开发新功能
release/xxx
发布分支
版本发布前测试与修复
hotfix/xxx
紧急修复分支
修复线上严重问题
xxx_dev
个人开发分支
仅限本地使用
开发完成后合并回 develop
🌐 Git Flow架构图（详细版 ）
创建分支
创建分支（本地）
PR 合并
push
PR
创建分支（本地）
PR 合并
PR 合并
push
PR
PR
紧急修复创建（本地）
PR 合并
PR 合并
push
PR
PR
创建分支（本地）
PR 合并
push
PR
main
主分支
生产环境
develop
开发基线
集成所有功能
feature/xxx
功能分支
开发新功能
✓ 合并后建议删除
origin/feature/xxx
远程功能分支
用于 PR 和代码审查
release/xxx
发布分支
版本发布前测试与修复
✓ 合并后建议删除
origin/release/xxx
远程发布分支
暂存待发布的版本
hotfix/xxx
紧急修复分支
修复线上严重问题
✓ 合并后建议删除
origin/hotfix/xxx
远程紧急修复分支
用于审查和合并
xxx_dev
个人开发分支
仅限本地使用
开发完成后合并回 develop
✓ 合并后建议删除
origin/xxx_dev
远程个人分支
可选：用于协作或备份
解释说明
💡 图中有看到本地直接提PR/MR，这属于 本地git mr方式（单仓模式），也就是不用将本地分支推送到远端，即可直接创建从本地分支到远端的主库的MR。
✅ 总结
- ✅ 使用 标准 Git Flow 工作流图 作为参考（如 Atlassian 官方图）。
- ✅ 所有合并操作必须遵循 "从下往上" 的原则：feature → develop，develop → release，release → main。
- ✅ 紧急修复（hotfix）是例外，但必须通过专用分支完成，不能直接合并 main 到 develop
Q&A
🔍 为什么不能把 main 合并到 develop？
原因一：破坏开发基线的稳定性
- develop 是所有新功能的集成点。
- 如果 main 的代码被合并到 develop，可能会引入未经测试的生产代码，污染开发环境。
原因二：违反"单向流动"原则
- Git Flow 设计为 从开发 → 发布 → 生产 的单向流程。
- 任何"反向合并"都可能导致分支污染、版本混乱、CI/CD 失效等问题。
原因三：紧急修复（hotfix）的处理方式已提供了"反向"通道
- 在 Git Flow 中，hotfix 分支是从 main 创建的，修复完成后合并回 main 和 develop。
- 这正是 "从 main 向 develop 合并" 的唯一合法场景！
- 但注意：这是通过 hotfix 分支完成的，不是直接在 main 和 develop 之间建立箭头