Git 新手入门：一文搞懂分支命名规范与 Git Flow，feature、bugfix、hotfix、release 到底有什么区别

下面是一版“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分支
• 线上出问题要走hotfix
• main不能随便直接提交

于是问题就来了：

• feature是 Git 自带的吗？
• bugfix和hotfix到底有什么区别？
• 分支名应该怎么命名才规范？
• main、develop、feature、release、hotfix之间到底是什么关系？
• 像feature/zhangsan/profiling这种写法到底合不合理？

这篇文章就专门面向 Git 新手，系统讲清楚两件事：

1. Git 分支命名规范
2. 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：修普通 Bug
• hotfix：修线上紧急问题
• 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/*最后合回develop
• bugfix/*最后合回develop
• release/*最后合回main
• hotfix/*最后先合回main，再同步回develop

5. 生命周期不同

• 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-refund

2. 修普通 Bug

bugfix/login-null-check bugfix/order-status-error

3. 修线上紧急问题

hotfix/payment-timeout hotfix/security-patch

4. 准备发版

release/1.0.0 release/2.3.1

5. 改文档

docs/api-guide docs/deploy-readme

6. 重构

refactor/auth-module refactor/order-service

7. 杂项维护

chore/upgrade-node18 chore/update-eslint

十、推荐的命名原则

给 Git 新手 6 个最实用的建议。

1. 先写类型，再写内容

例如：

feature/login bugfix/order-status docs/readme

2. 内容尽量简短清晰

不要太短，也不要太长。

推荐：

feature/user-login

不推荐：

feature/do-something-about-the-user-login-page-and-related-api

3. 使用英文或统一拼音，不要中英混搭

推荐统一使用英文，更专业，也更通用。

例如：

feature/user-login bugfix/payment-timeout

4. 单词之间用-连接

推荐：

feature/user-login hotfix/payment-timeout

不推荐：

feature/user_login feature/userLogin

不是说后两者绝对错误，而是团队里统一最重要。

5. 不要用无意义名字

不推荐：

testaaa tmp fix new zhangsan

6. 拼写一定要检查

例如：

• profiling是对的
• profilling很可能是错的

分支名虽然不会影响程序运行，但会影响团队阅读体验。

十一、推荐一套适合新手直接照抄的规范

如果你不知道从哪开始，可以直接用下面这套。

长期分支

main develop

短期分支

feature/<function-name>bugfix/<bug-name>hotfix/<urgent-fix-name>release/<version>docs/<doc-name>refactor/<module-name>chore/<task-name>test/<test-name>ci/<pipeline-name>perf/<optimization-name>

例如：

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 的核心思想可以概括成两句话：

1. 正式上线代码和日常开发代码分开管理
2. 新功能开发、发布准备、线上紧急修复分别走不同分支

所以它通常会有两条长期分支：

• main：正式版本主线
• develop：日常开发主线

以及三类短期分支：

• feature/*：新功能开发
• release/*：发版准备
• hotfix/*：线上紧急修复

十四、Git Flow 分支流转图（Mermaid 版）

下面直接用 Mermaid 图来看 Git Flow 的流转关系。

1）总览图