下面是一版“CSDN 可直接发布的完整版成稿”，我已经把标题、前言、正文、文字说明、Mermaid 图、总结全部整合成一篇，直接复制到 CSDN 基本就能发。
Git 新手入门：一文搞懂分支命名规范与 Git Flow，feature、bugfix、hotfix、release到底有什么区别？很多 Git 新手在刚接触团队协作时，都会看到这样的分支名：
feature/login bugfix/order-status hotfix/payment-timeout release/1.2.0也经常会在项目中听到这些说法：
新功能从develop拉一个feature分支发版前切一个release分支线上出问题要走hotfixmain不能随便直接提交于是问题就来了：
feature是 Git 自带的吗？bugfix和hotfix到底有什么区别？分支名应该怎么命名才规范？main、develop、feature、release、hotfix之间到底是什么关系？像feature/zhangsan/profiling这种写法到底合不合理？这篇文章就专门面向 Git 新手，系统讲清楚两件事：
Git 分支命名规范Git Flow 分支流转关系你可以把它当作一篇 Git 分支入门指南来看。
一、先搞懂：feature、hotfix、release不是 Git 官方内置类型很多人一开始会误以为：
feature是功能分支hotfix是热修复分支release是发布分支看起来像是 Git 官方自带的“特殊分支类型”。
其实不是。
Git 本身只认识 branch，并不认识feature、bugfix、hotfix、release这些前缀。
也就是说：
feature/login hotfix/payment release/1.0.0对 Git 来说，本质上都只是普通分支名。
这些前缀真正的价值在于：
让团队成员一眼就知道：这条分支是干什么的、从哪来、以后要合到哪去。
所以它们不是 Git 的语法要求，而是团队协作规范。
二、为什么团队要规范分支命名？因为团队开发里分支会很多。
如果大家都这样起名：
testaaa new fix1 temp zhangsan别人根本不知道这条分支是干什么的。
但如果统一这样写：
feature/user-login bugfix/order-status hotfix/payment-timeout release/2.1.0含义就很清楚：
feature：开发新功能bugfix：修普通 Bughotfix：修线上紧急问题release：准备发版所以分支命名规范最核心的价值，就是两个字：
清晰三、Git 中最常见的分支类型及作用1.main或master这是主分支。
现在大多数新项目都使用main，老项目可能还在使用master。
作用通常表示：
正式代码稳定代码可发布代码线上运行代码特点生命周期最长通常权限最严格一般不允许随便直接提交往往通过 PR（Pull Request）合入一句话理解main就是正式版本主线。
2.develop这是开发主线分支，常见于Git Flow工作流。
作用用于团队日常开发集成：
新功能先合到这里普通 Bug 先修到这里发布前可能从这里切出release/*特点比main更活跃不一定像main那样绝对稳定适合作为开发和测试集成主线一句话理解main是正式版，develop是开发版。
3.feature/*表示功能开发分支。
例如：
feature/user-login feature/order-export feature/refund-api作用开发一个新功能、新页面、新接口、新需求。
一般流程通常从develop或main切出来，开发完成后再合回去。
特点短生命周期功能完成后一般会删除用来隔离开发中的不稳定代码适用场景新增登录功能新增订单导出新增支付接口新增后台模块一句话理解feature/*就是“我正在做一个新功能”。
4.bugfix/*表示普通 Bug 修复分支。
例如：
bugfix/login-null-check bugfix/order-status-error作用修复开发阶段或测试阶段发现的问题。
适用场景测试发现页面报错接口字段处理错误逻辑判断写错非线上紧急问题和hotfix的区别bugfix/*一般用于：
正常开发流程中的缺陷修复可以按正常排期解决的问题不属于线上事故一句话理解bugfix/*是正常节奏下修 Bug。
5.hotfix/*表示线上紧急修复分支。
例如：
hotfix/payment-timeout hotfix/security-patch hotfix/crash-on-startup作用修复已经上线的严重问题。
常见场景线上服务崩了支付失败核心接口不可用权限漏洞严重数据错误特点优先级很高流程通常更快修复范围要尽可能小和bugfix的核心区别bugfix/*修的是开发中的问题hotfix/*修的是线上正在出问题的正式版本一句话理解hotfix/*就是“线上着火了，赶紧修”。
6.release/*表示发布准备分支。
例如：
release/1.2.0 release/2026.04作用为某个版本发布做最后准备。
里面通常做什么修改版本号补充发布说明做最后测试修少量发布前问题冻结新功能进入特点一般不再新增需求重点在“收尾”和“稳定”发布完成后通常要合回主分支一句话理解release/*就是“这版准备上线了，先冻结出来做最后收尾”。
四、其他常见分支前缀除了上面几个常见类型，很多团队还会用下面这些前缀。
1.chore/*表示杂项维护。
例如：
chore/update-eslint chore/upgrade-dependencies chore/cleanup-scripts用途升级依赖改配置调整脚本做项目清理2.docs/*表示文档修改。
例如：
docs/api-guide docs/deploy-readme用途改 README改接口文档改部署文档改使用说明3.refactor/*表示重构。
例如：
refactor/order-service refactor/auth-module用途优化代码结构提高可维护性模块拆分减少重复代码4.test/*表示测试相关修改。
例如：
test/add-unit-tests test/login-e2e用途新增单元测试修改测试代码增加自动化测试5.ci/*表示持续集成、持续部署相关改动。
例如：
ci/fix-github-actions ci/update-pipeline用途修改 GitHub Actions修改 GitLab CI修改 Jenkins 流水线调整自动部署流程6.perf/*表示性能优化。
例如：
perf/query-cache perf/reduce-render-time用途SQL 优化缓存优化渲染优化接口性能优化7.spike/*或experiment/*表示试验性分支。
例如：
spike/graphql-gateway experiment/new-search用途技术预研原型验证可行性测试一句话理解先试试，不一定最终上线。
五、这些分支前缀真正的区别是什么？很多新手只看到“名字不一样”，但其实它们真正区分的是下面几件事。
1. 目的不同feature/*：开发新功能bugfix/*：修普通问题hotfix/*：修线上紧急问题release/*：准备发版2. 紧急程度不同一般可以这样理解：
hotfix > bugfix > feature也就是说：
hotfix最急bugfix次之feature一般按计划开发3. 来源分支可能不同常见情况下：
feature/*从develop切bugfix/*从develop切release/*从develop切hotfix/*从main切4. 最终合并目标不同例如：
feature/*最后合回developbugfix/*最后合回developrelease/*最后合回mainhotfix/*最后先合回main，再同步回develop5. 生命周期不同main、develop：长期分支feature/*、bugfix/*、hotfix/*：短期分支release/*：阶段性分支六、Git 新手最容易犯的误区误区 1：以为feature是 Git 官方内置分支类型不是。
Git 并没有“功能分支”“热修复分支”这种内置概念，它只认识普通 branch。
误区 2：觉得分支名随便写都可以技术上当然可以，但团队协作里不推荐。
比如这些名字就很差：
testaaa newbranch fix temp zhangsan因为别人根本看不懂。
误区 3：把分支名写得太长例如：
feature/add-a-new-user-login-page-with-phone-code-and-remember-password-function虽然能看懂，但太长了，不利于阅读和输入。
建议简洁明确。
误区 4：拼写错误不当回事例如：
feature/zhangsan/profilling其中profilling很可能是拼写错误。
如果你想表达“性能分析”或“剖析”，更合理的写法通常是：
feature/zhangsan/profiling或者更推荐直接写成：
feature/performance-profiling分支名虽然只是名字，但拼写错误会降低专业度，也会影响团队理解。
七、分支命名到底该怎么写？推荐一个非常实用的模板：
type/short-description例如：
feature/user-login bugfix/order-status hotfix/payment-timeout release/2.1.0 docs/api-guide refactor/auth-module如果团队想表达得更细，也可以写成：
type/module-description例如：
feature/auth-login bugfix/order-status-display refactor/user-service perf/query-cache八、分支名中要不要带人名？很多新手会写成这样：
feature/zhangsan/profiling这种写法不是不行，但通常不算最优。
1. 这种写法的优点能看出是谁创建的多人协作时，临时区分比较方便2. 这种写法的问题分支名重点变成了“谁在做”，而不是“做什么”人员变动后名字可能失去意义别人接手时不够自然PR 和提交记录里本来就能看到开发者3. 更推荐的做法优先让分支名表达“任务内容”。
例如：
feature/profiling feature/performance-profiling feature/login-api-profiling如果团队明确要求必须带人名，那也可以保留：
feature/zhangsan/profiling但前提是：
团队确实有统一规范命名结构统一拼写正确九、推荐给新手的分支命名规范如果你是个人项目，或者小团队刚开始建立规范，我建议直接采用下面这套，简单又实用。
1. 功能开发feature/user-login feature/order-export feature/payment-refund2. 修普通 Bugbugfix/login-null-check bugfix/order-status-error3. 修线上紧急问题hotfix/payment-timeout hotfix/security-patch4. 准备发版release/1.0.0 release/2.3.15. 改文档docs/api-guide docs/deploy-readme6. 重构refactor/auth-module refactor/order-service7. 杂项维护chore/upgrade-node18 chore/update-eslint十、推荐的命名原则给 Git 新手 6 个最实用的建议。
1. 先写类型，再写内容例如：
feature/login bugfix/order-status docs/readme2. 内容尽量简短清晰不要太短，也不要太长。
推荐：
feature/user-login不推荐：
feature/do-something-about-the-user-login-page-and-related-api3. 使用英文或统一拼音，不要中英混搭推荐统一使用英文，更专业，也更通用。
例如：
feature/user-login bugfix/payment-timeout4. 单词之间用-连接推荐：
feature/user-login hotfix/payment-timeout不推荐：
feature/user_login feature/userLogin不是说后两者绝对错误，而是团队里统一最重要。
5. 不要用无意义名字不推荐：
testaaa tmp fix new zhangsan6. 拼写一定要检查例如：
profiling是对的profilling很可能是错的分支名虽然不会影响程序运行，但会影响团队阅读体验。
十一、推荐一套适合新手直接照抄的规范如果你不知道从哪开始，可以直接用下面这套。
长期分支main develop短期分支feature/
feature/user-login feature/order-export bugfix/order-status hotfix/payment-timeout release/1.2.0 docs/api-guide refactor/auth-module chore/update-eslint test/login-e2e ci/fix-github-actions perf/query-cache十二、一个具体例子：feature/zhangsan/profiling合不合理？这个名字从 Git 语法上说没问题：
feature/zhangsan/profiling它的大致含义是：
feature：功能分支zhangsan：负责人profiling：做 profiling 相关工作但是从团队协作角度看，它只能算“可用”，不算“最佳”。
更推荐的写法如果团队没有强制要求带人名，更建议写成：
feature/profiling feature/performance-profiling feature/login-api-profiling如果团队明确要求带人名，那可以写成：
feature/zhangsan/profiling但不要写成：
feature/zhangsan/profilling因为profilling很可能是拼写错误。
十三、接下来再搞懂 Git Flow：main、develop、feature、release、hotfix之间到底是什么关系？上面讲的是命名。
但在真实项目里，新手更容易困惑的是：
为什么功能分支通常从develop拉？为什么发版要切release/*？为什么线上出问题要从main拉hotfix/*？为什么修完之后还要同步回develop？这就涉及到 Git 中一个非常经典的工作流：Git Flow。
Git Flow 的核心思想可以概括成两句话：
正式上线代码和日常开发代码分开管理新功能开发、发布准备、线上紧急修复分别走不同分支所以它通常会有两条长期分支：
main：正式版本主线develop：日常开发主线以及三类短期分支：
feature/*：新功能开发release/*：发版准备hotfix/*：线上紧急修复十四、Git Flow 分支流转图（Mermaid 版）下面直接用 Mermaid 图来看 Git Flow 的流转关系。
1）总览图