五大分支概述

- 主分支 (main/master): 项目的生产发布分支, 始终保持稳定可发布状态
- 热修复分支 (hotfix/*): 从
main分支创建, 用于紧急修复线上 BUG, 修复后同时合并回main和develop - 开发分支 (develop): 日常开发的主分支, 所有功能开发的集成分支
- 特性分支 (feature/*): 从
develop创建, 开发新功能, 完成后合并回develop - 预发布分支 (release/*): 从
develop创建, 用于发布前的测试和最终调整, 测试通过后合并回main(打版本标签) 和develop
分支合并关系
feature/* → develop
develop → release/*
release/* → main + develop
hotfix/* → main + develop主分支
作用: 存放 稳定, 可随时部署到生产环境的代码
特点:
- 分支上每一个提交对都应一个正式发布的版本
- 不允许在此分支直接开发
- 通常被打上版本标签 (如: v1.0.0 或 v20260101)
开发分支
作用: 存放 最新开发成果 的集成分支, 是功能开发的集线器
特点:
- 当
develop分支上的代码到达稳定状态并准备发布时, 会合并到main分支 (如果有release分支, 则合并到此分支) - 所有功能的分支、发布分支都从
develop分支拉取
功能分支
来源: develop
合并目标: develop
命令惯例:feature/user-authentication,feature/payment-integration
作用: 开发新功能
生命周期:
- 从
develop分支拉取 - 开发完成后, 合并回
develop - 合并后, 该功能分支通常被删除
发布分支
来源: develop
合并目标:develop 和 main
命名惯例:release/1.2.0,release/2026-spring
作用: 为发布新版本做准备. 在此分支上, 只做 BUG 修复,生成版本号,整理文档 等发布准备工作, 不再添加新功能
生命周期:
- 当
develop分支的功能足够进行一次发布时, 从develop拉出release分支 - 在此分支上进行最后的测试和修复
- 准备就绪后, 将
release分支合并到main分支 并打上版本标签 - 同时, 必须合并回
develop分支, 因为release分支上修复的 BUG 可能develop分支上还没修复
热修复分支
来源:main
合并目标:main和develop
命名惯例:hotfix/critical-security-patch,hotfix/1.2.1
作用:快速修复生产环境(main分支)上的紧急BUG
生命周期:
- 从
main分支上出现BUG的提交点(通常是最近的标签)拉取 - 修复完成后,合并回
main分支并打上新的版本标签(如:v1.0.1) - 同时,必须合并回
develop分支,确保修复在后续开发中也生效
人话
恭喜你能看到这里, 理论看起来确实是枯燥的, 感谢你自己的坚持,
希望评论区就
gitflow能展开相关讨论, 而不是一味的刷 感谢分享 感谢大佬,我分享文章也是希望有思想和经验上的交流碰撞
实际上,普通的开发入职后,如果有开发需求,一般都是从develop分支拉取代码后,
本地新建 feature/xxx 功能分支,在feature/xxx 分支上进行开发的
功能开发到一定阶段后,比如一阶段完成了核心需求(因为产品可能在开发内提出新需求,这很常见),
就可以合并到 develop 分支, develop 在积累了多个功能分支合并后,
就可以发布到 release 发布分支, 这一分支不再接受新功能合并, 只允许修补 BUG
这一过程就是提测, 让测试工程师核验功能完整性, 如果有 BUG 要及时修复
修复的时候拉取的是 release 分支,然后提交的时候也是推送到这个分支
在 release 分支准备完善 (修复了测试工程师检测到的 BUG),就可以准备往主分支 (main) 发布了,
这就是一次完整的 git flow 发布流程, 当然还有线上有 BUG, 需要做紧急修复
这个时候, 就是直接拉取 main 分支并在本地创建热修复分支 hotfix,
在 BUG 被修复后, 就可以合并回 main 分支 和 develop 分支了
是的, 这里要注意, hotfix 要合并到 2 个分支里,
而不是 hotfix->main->develop 这是错误的做法, 因为造成 develop 被 main 污染 (额外的标签记录以及其他)
大家有什么想法也可以在评论区里说一下, 也可能有我没有讲到地方, 大家也可以补充

📌 评论规则
需要 GitHub 账号登录 禁止发布广告、无关内容 请保持友善讨论