一、主干分支

Git 仓库里的默认分支，分支名通常是 main 或者 master，是一定会存在的分支，有且只有一个。无论是哪种分支模型，人们对于主干分支的期望都是稳定性，希望其中的代码是可以立即部署到生产环境。

二、开发分支（Develop Branch)

在实际生产中，人们慢慢发现，功能开发好并不代表着能立即投入生产，这中间还需要一定的缓冲与隔离，于是开发分支应运而生，新开发的功能暂存在开发分支，等开发分支的稳定性和健壮性得到足够验证后，再同步代码到主干分支。

分支名通常是 develop 或者 dev，一个仓库里一般只会有一个开发分支，在 Gitflow 分支模型里，开发分支只能从主干分支拉出。

三、功能分支（Feature Branch）

当单个仓库的活跃开发者变多时，大家同时往主干分支或者开发分支推送代码时，常常面临很多棘手的问题，比如过于频繁的代码冲突等等。

于是人们渐渐开始尝试特性分支的形式，每次开发一个新功能或者修复一个 bug 时，拉出一个单独的分支，打造一个隔离的开发环境，这样多位开发可以同时独立地开发自己的功能特性，而不会相互干扰。

特性分支更是在 2008 年 GitHub 发明 Pull Request 之后，火速串红，成为代码开发的标配。特性分支在合入主干分支或者开发分支之前，发起一个 Pull Request，团队成员对特性分支的代码改动进行评审，以及在自动化测试流水线的加持之下，特性分支的代码稳定性得到了充分保障，极大提高了软件的质量。

分支名通常是 feature/、feature-、*-feature、feat/ 或者不限定命名规范，一般是从主干分支或者开发分支拉出。

四、发布分支（Release Branch）

功能合并到主干或者开发分支后，并不是软件开发的终点，还需要将新版软件交付到生成环境，这期间往往不是一帆风顺，会有一些小插曲发生，比如临时修改部分文档，或者小型的 bug 修复，但同时开发已经开始了新一个迭代的功能开发，可能已经有新的特性合入主干或者开发分支。

这时候就需要专门的发布分支，将用于新版本的代码隔离，即不会阻碍新迭代新功能的合入，也能便于对当下版本进行些小修改。

分支名通常是 release/、release-、-release、rel- 或者 **-stable 等等，一般是从主干分支或者开发分支拉出。

五、热修复分支（Hotfix Branch）

最新代码部署到生产环境后，仍不是旅程的终点，可能在最新版软件运行一段时间，部分用户反馈了一个严重的 bug，这时候就不得不对生产代码进行热修复。

此时，需要从生产环境对应的分支，例如发布分支或者生产分支，拉出一个补丁分支，只进行这个严重的线上 bug 修复。

六、环境分支

有些团队会针对不同部署环境，例如 staging、pre-production、production，各建一条分支，再配合部署流水线，自动将不同环境分支的最新代码部署到对应的环境。