Git 分支命名、区别、联系与顺序关系说明

1. 先理解 Git 里的几个核心对象

Git 中很多名称看起来像"分支"，但实际类型不同：

名称	是不是分支	准确含义	常见示例
本地分支 local branch	是	存在于本机仓库的可提交分支	`main`、`develop`、`feature/login`
远程跟踪分支 remote-tracking branch	是一种本地只读引用	本机记录的远程分支状态	`origin/main`、`origin/develop`
远程仓库 remote	不是分支	一个远程仓库地址的别名	`origin`、`upstream`
origin	不是分支	默认远程仓库名称，一般指克隆来源	`origin`
tag	不是分支	某个提交点的固定标记，多用于版本发布	`v1.0.0`、`release-2026-05-19`
HEAD	不是分支	当前工作区指向的提交或分支	`HEAD -> main`
commit	不是分支	一次代码快照	`a1b2c3d`

一句话总结：

main、master、develop、test、hotfix/xxx 通常是分支。
origin 是远程仓库别名，不是分支。
origin/main 是远程跟踪分支，不是本地可直接提交的普通分支。
tag 是版本快照标记，不是分支。

2. main 与 master

2.1 含义

main 和 master 通常都表示主干分支，也就是项目最稳定、最正式的主分支。

分支名	含义	说明
`master`	老式默认主分支名	很多老项目使用
`main`	新式默认主分支名	近几年很多平台默认使用

2.2 区别

技术上没有本质区别，都是普通分支。区别主要来自团队约定：

老项目常见：master
新项目常见：main
有些团队同时存在，但通常只应选择一个作为生产主干，避免混乱。

2.3 常见用途

main 或 master 一般代表：

可发布到生产环境的代码。
已通过测试和评审的稳定代码。
发布版本打 tag 的来源分支。

2.4 注意事项

不建议直接在 main/master 上开发功能。
不建议随意 force push 到 main/master。
通常应开启分支保护：禁止直接 push，必须通过 Pull Request 或 Merge Request 合并。

3. develop

3.1 含义

develop 通常是开发集成分支，用来汇总多个功能分支的代码。

典型定位：

text 复制代码

feature/* -> develop -> test/release -> main/master

3.2 作用

接收日常功能开发完成后的合并。
作为开发环境或联调环境的部署来源。
多人协作时，用来提前发现模块之间的冲突。

3.3 与 main/master 的区别

对比项	`develop`	`main/master`
稳定性	中等，可能存在未发布功能	高，通常可生产发布
用途	开发集成、联调	生产发布、正式版本
允许变更频率	较高	较低
是否可直接部署生产	一般不建议	通常可以

3.4 注意事项

develop 上的代码不一定等于生产代码。
合并到 develop 前也应保证本地基本可编译、核心测试通过。
多人频繁合并时，应经常从 develop 同步最新代码，减少冲突堆积。

4. feature 分支

4.1 含义

feature/* 是功能开发分支。虽然用户列举里没有 feature，但实际开发最常用。

示例：

text 复制代码

feature/login
feature/bpm-model-editor
feature/starfirm-contract-renewal

4.2 作用

每个功能独立开发。
避免直接污染 develop 或 main。
方便代码评审、测试、回滚和并行开发。

4.3 来源和归宿

一般从 develop 拉出，完成后合回 develop：

bash 复制代码

git switch develop
git pull
git switch -c feature/xxx
# 开发、提交
git push -u origin feature/xxx
# 提交 MR/PR 到 develop

4.4 命名建议

text 复制代码

feature/模块-功能
feature/需求编号-简短描述
feature/bpm-process-model
feature/JIRA-1234-login-sso

5. test、testing、qa、uat

5.1 含义

test、testing、qa、uat 通常表示测试环境相关分支。

分支名	常见含义
`test`	测试环境分支
`testing`	测试分支，含义与 `test` 类似
`qa`	QA 测试环境分支
`uat`	用户验收测试环境分支

5.2 作用

作为测试环境部署来源。
汇总即将测试的功能。
在发布前进行验证、验收、回归。

5.3 与 develop 的区别

对比项	`develop`	`test/qa/uat`
主要角色	开发集成	测试验证
代码来源	功能分支合入	通常从 develop 或 release 合入
稳定性	中等	应高于 develop
是否允许频繁提交	可以较频繁	应控制变更，避免影响测试

5.4 注意事项

test 分支不一定是 Git 标准分支，而是团队协作习惯。
如果测试环境可以直接部署某个 commit 或 tag，也可以不长期维护 test 分支。
避免把测试专用临时代码合回主干。

6. release 分支

6.1 含义

release/* 通常表示发布准备分支。

示例：

text 复制代码

release/1.0.0
release/2026-05-19
release/v2.3.0

6.2 作用

从 develop 拉出一个即将发布的候选版本。
只接收发布必要的 bug 修复、版本号调整、配置修正。
测试通过后合并到 main/master 并打 tag。
发布修复也应同步回 develop。

6.3 常见流程

text 复制代码

feature/* -> develop -> release/x.y.z -> main/master -> tag vX.Y.Z
                              \-> develop

6.4 注意事项

不建议在 release 分支继续开发大功能。
只做稳定性修复和发布准备。
发布完成后可以删除 release 分支，保留 tag 即可。

7. hotfix

7.1 含义

hotfix/* 表示生产紧急修复分支。

示例：

text 复制代码

hotfix/login-token-expired
hotfix/20260519-payment-error
hotfix/v1.2.1

7.2 作用

当生产环境出现紧急问题时，不等下一轮正常发布，直接从生产主干或生产 tag 拉出修复分支。

7.3 来源和归宿

典型流程：

text 复制代码

main/master -> hotfix/xxx -> main/master -> tag
                         \-> develop
                         \-> release/test（如存在）

7.4 为什么要回合 develop

因为生产修复如果只合到 main/master，而没有同步到 develop，后续从 develop 发布时可能把修复覆盖掉，导致问题复现。

7.5 注意事项

hotfix 应保持最小改动，只修复生产问题。
不应顺手带入无关重构或新功能。
修复后必须同步到开发分支和正在测试的发布分支。

8. bugfix、fix

8.1 含义

bugfix/* 或 fix/* 通常表示普通缺陷修复分支。

示例：

text 复制代码

bugfix/search-null-pointer
fix/bpm-task-list-empty

8.2 与 hotfix 的区别

对比项	`bugfix/fix`	`hotfix`
紧急程度	普通缺陷	生产紧急缺陷
来源	多数从 `develop` 或当前开发分支拉出	多数从 `main/master` 或生产 tag 拉出
发布方式	随下一版本发布	立即发布或快速发布
合并目标	`develop`、`release`	`main/master`，并回合 `develop`

9. tags

9.1 tag 不是分支

tag 是对某个 commit 的命名标记，通常表示版本发布点。

示例：

text 复制代码

v1.0.0
v1.0.1
release-2026-05-19

9.2 tag 与 branch 的区别

对比项	branch	tag
是否会移动	会，随着提交前进	通常不应移动
是否用于继续开发	是	否
典型用途	功能开发、集成、发布准备	标记版本、标记里程碑
引用位置	`refs/heads/*`	`refs/tags/*`

9.3 tag 类型

类型	命令	特点
轻量标签	`git tag v1.0.0`	只是一个名字指向 commit
附注标签	`git tag -a v1.0.0 -m "release v1.0.0"`	包含作者、时间、说明，推荐用于正式发布

9.4 常见流程

bash 复制代码

git switch main
git pull
git tag -a v1.0.0 -m "release v1.0.0"
git push origin v1.0.0

10. remote、origin、upstream

10.1 remote 是什么

remote 是远程仓库配置，不是分支。

查看远程仓库：

bash 复制代码

git remote -v

可能输出：

text 复制代码

origin   https://example.com/company/project.git (fetch)
origin   https://example.com/company/project.git (push)

10.2 origin 是什么

origin 是默认远程仓库名称。通常通过 git clone 克隆下来时，Git 自动把克隆来源命名为 origin。

10.3 upstream 是什么

upstream 常用于 fork 协作场景：

origin：自己的 fork 仓库。
upstream：原始主仓库。

示例：

bash 复制代码

git remote add upstream https://example.com/original/project.git
git fetch upstream

10.4 origin/main 是什么

origin/main 是本地保存的"远程 main 分支状态"，不是远程仓库上的真实分支本身，也不是普通本地分支。

更新它需要：

bash 复制代码

git fetch origin

11. local 与 remote 分支

11.1 local branch

本地分支是你当前机器上的分支，可以提交。

bash 复制代码

git branch

示例：

text 复制代码

* develop
  feature/login
  main

11.2 remote branch / remote-tracking branch

远程跟踪分支表示本机记录的远程分支状态：

bash 复制代码

git branch -r

示例：

text 复制代码

origin/main
origin/develop
origin/feature/login

11.3 本地分支与远程分支的关联

本地分支可以设置 upstream，表示默认从哪个远程分支拉取、默认推送到哪里。

查看关联：

bash 复制代码

git branch -vv

设置关联：

bash 复制代码

git push -u origin feature/login

12. 分支之间有没有顺序关系

12.1 Git 本身没有固定顺序

Git 的底层是提交图，是一个有向无环图。分支只是指向某个 commit 的名字。Git 不规定 develop 必须在 main 前面，也不规定 test 必须在 release 后面。

也就是说：

分支没有天然等级。
分支没有天然上下级。
分支没有 Git 强制的先后顺序。

12.2 顺序来自团队工作流

常见团队会人为约定顺序。例如 Git Flow：

text 复制代码

feature/* -> develop -> release/* -> main/master -> tag
                     \-> test/qa/uat
main/master -> hotfix/* -> main/master -> tag
                         \-> develop

简化工作流可能是：

text 复制代码

feature/* -> develop -> main/master -> tag

更轻量的 trunk-based development 可能是：

text 复制代码

feature/* -> main -> tag

12.3 常见稳定性层级

虽然 Git 不强制，但团队通常会按稳定性理解：

text 复制代码

feature < develop < test/qa/uat < release < main/master < tag

注意：这是经验顺序，不是 Git 规则。

13. 常见分支命名规范

13.1 推荐命名格式

text 复制代码

类型/需求号-简短描述

示例：

text 复制代码

feature/JNPF-1234-bpm-model-editor
bugfix/JNPF-1240-task-list-empty
hotfix/20260519-login-error
release/1.2.0
chore/update-maven-version
docs/git-guide

13.2 常见类型

类型	用途
`feature/`	新功能
`bugfix/`	普通 bug 修复
`fix/`	普通修复，含义接近 `bugfix`
`hotfix/`	生产紧急修复
`release/`	发布准备
`docs/`	文档
`chore/`	构建、配置、脚本、依赖等杂项
`refactor/`	重构
`test/`	测试代码或测试分支，注意不要与环境分支 `test` 混淆
`experiment/`	实验性验证

13.3 命名注意事项

使用小写字母、数字、短横线，减少空格和中文。
不建议使用特殊字符，如 ~、^、:、?、*、[。
分支名要短，但要能看懂。
同一个团队应统一规则。
不要让分支名与 tag 名完全相同，容易产生引用歧义。

14. 推荐工作流示例

14.1 常规功能开发

text 复制代码

1. 从 develop 拉出 feature/xxx
2. 在 feature/xxx 开发并提交
3. 推送到 origin/feature/xxx
4. 提交 MR/PR 到 develop
5. 代码评审与 CI 通过后合入 develop
6. 测试阶段从 develop 合入 test 或 release
7. 发布时 release 合入 main/master 并打 tag

14.2 生产紧急修复

text 复制代码

1. 从 main/master 或生产 tag 拉出 hotfix/xxx
2. 修复问题并验证
3. 合入 main/master
4. 打新 tag，例如 v1.0.1
5. 同步合入 develop
6. 如果存在 release/test 分支，也同步合入对应分支

14.3 小团队轻量流程

text 复制代码

1. 所有人从 main 拉 feature/xxx
2. 功能完成后 MR/PR 到 main
3. main 保持可发布
4. 每次发布在 main 上打 tag

15. 常见误区

误区	正确认识
`origin` 是一个分支	`origin` 是远程仓库别名，不是分支
`origin/main` 就是远程仓库上的 main	它是本地记录的远程 main 状态，需要 fetch 更新
`tag` 可以当分支继续开发	tag 是固定版本标记，不适合继续开发
`main` 一定比 `master` 高级	两者只是名字不同，技术上等价
`develop` 一定存在	取决于团队流程，不是 Git 必须有
`test` 分支一定代表测试环境	只是命名约定，真实含义看团队规定
分支有天然上下级	Git 没有分支等级，只有提交图和引用
删除本地分支会删除远程分支	删除本地分支不会自动删除远程分支

16. 建议团队规范

明确主分支：统一使用 main 或 master，不要混用。
明确开发集成分支：如使用 develop，就规定所有功能先合入 develop。
明确发布策略：是否使用 release/*，是否每次发布必须打 tag。
明确热修复策略：hotfix/* 必须回合 develop。
明确分支保护：主分支禁止直接 push，必须 PR/MR。
明确命名规范：分支名前缀、需求编号、描述格式统一。
明确清理周期：已合并的 feature 分支定期删除。
明确冲突处理责任：谁改动谁负责解决，避免随意覆盖他人代码。

17. 一句话记忆

main/master：正式主干。
develop：开发集成。
feature/*：功能开发。
test/qa/uat：测试验证。
release/*：发布准备。
hotfix/*：生产紧急修复。
tag：版本快照。
origin：远程仓库别名。
origin/main：远程主分支在本地的跟踪引用。
分支没有天然顺序，顺序来自团队工作流。