Git 最强大的就是其分支功能，但是如何分支才能更有效的提高开发效率，减少因为代码合并带来的问题，需要一个分支模型来规范，其实在 Git Flow 出现之前，已经有分支模型理论流程，当时是根据此理论，手动的按照规范操作分支，Git Flow 出现之后，将一部分操作流程简化为命令，并没有增加新的功能，只是简化了操作。

统一团队的 Git 工作流，包括分支使用、Tag 规范、Issue 等统一团队的 Git Commit 日志标准，便于后续代码 Review，版本发布以及日志自动化生成

分支管理

Git Flow 管理方式把项目分为 6 条线，通常会是下面的管理方式

main分支

作为稳定主分支，用于部署生产环境的分支，长期有效
保护分支，不可以在此分支进行任何提交，只能接受从 hotfix 分支或者 release 分支发起的 Merge Request
该分支上的每一个提交都对应一个 Tag 提交标签。

develop分支

主开发分支，长期有效
新功能或 bug 修复分支都从这里拉取和提合并请求。
保护分支，不可以在此分支上做任何提交，只接受从 feature 分支发起的 Merge Request。所有的 Alpha Release 都应该在这个分支发布。
建议设置为仓库默认分支

feature分支

新功能特性分支，生命周期为产品迭代周期，每个分支对应一期的需求
以 develop 为基础创建 feature 分支，可以 merge Release 分支的代码，生命周期结束后，需要 merge 回 Develop 分支。方式需要采用 Merge Request
短期分支
命名：feature/发布版本-功能名称。例如：feature/0.2.1-popcode分发

release分支

发布分支，声明周期从新需求的预发布到正式发布，每一个分支对应一个新版本的版本号。
只可以从 develop 分支 Kick Off。声明周期结束后，需要 merge 回 main 及 develop 分支，方式采用 Merge Request
所有的 Beta Release 均需要在该分支发布
用于回归测试，联调。如果当前项目是多人并行开发，各个 feature 自测后，合并到 develop，由于解决冲突不当，或者逻辑上和别的需求冲突，就会产生新的缺陷，这种情况就需要在 release 回归测试。
短期分支
命名：release/发布版本，例如：release/0.2.1。

hotfix分支

热修复分支，生命周期对应一个或者多个需要紧急修复并上线的 Bug，每一个分支对应一个小版本号
线上紧急 bug 修复的分支。
只可以从 main 拉取修复，声明周期结束后，合并到 main 中，并发布紧急修复版。后续需要将此修复合并到 develop 分支中。方式也是采用 Merge Request
短期分支
命名：hotfix/基于版本。例如：hotfix/0.2.0
如果多版本共存，就需要保留 hotfix 分支，后续该版本再出 bug，继续在该版本的 hotfix 分支上修改，并基于此分支发布修复版。

bugfix分支

bug 修复分支。
从 develop分支拉取，开发完毕并自测后需要合并到 develop 分支
短期分支
命名：bugfix/发布版本-功能名称。例如：bugfix/0.2.1-登录报错

在研发流程中分支通常对应不同的部署环境：

tag -> 生产环境（Production）
master -> 预发布/灰度环境（Pre-Production/Staging）
develop -> 测试环境（Test）

实际上，如果你熟悉 Git 的话，你会很快发现上面的管理方式会存在历史提交非常混乱的缺点，但觉得不失为一个 Git 分支管理的经典。实际上，我们可以用 rebase 去替换 merge 让 commit 看起来更加清晰。

Feature 开发流程

开发人员基于 develop 打 feature 分支，并推送到远端
在 Gitlab 提合并请求，标题里需要标识 WIP，例如 WIP: Feature/0.1.1 popcode分发
- WIP：Work In Progress，避免此合并请求被合并
开发功能，并经常 push
- 经常 push 可以让代码审核者关注进度，以及通过 Code Review 提前发现问题。
- 建议经常更新 develop 分支，并合并到当前 feature 分支，第一时间解决冲突，避免放到最后冲突一大堆了才去解决，导致误操作覆盖别人的代码。
- 同一分支合并使用 git fetch & git rebase 并解决冲突。不同分支合并使用 git fetch & git merge --no-ff 并解决冲突。
功能开发完，自测通过，删除合并请求里的 WIP 标识，并通知代码审核者。
代码审核者完成 Code Review ，成功合并到 develop
- 分支合并需要 PR 中勾选删除源分支。
当前版本的需求都合并到 develop 后，进入 release 阶段。基于 develop 创建该版本的 release 分支，进行回归测试。
在 release 分支上解决回归测试的 bug。
发起 release 分支合并到 main 的合并请求，并进行 Code Review。
- 分支合并需要 PR 中勾选删除源分支。
成功合并后，由 Maintainer 在 main 分支上打该版本的 tag，然后将 release 分支合并到 develop 分支
完成该版本发布

提交规范

业界使用比较广泛的代码提交规范是：Angular Git Commit Guidelines

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

占位标签解析：

type：代表某次提交的类型，比如是修复了 BUG 还是新增了 Feature
scope：说明 Commit 影响的范围，根据项目而定。例如在业务项目中可以依据菜单活功能模块划分；如果是组件库开发，则可以依据组件划分。
subject：Commit 的简短描述
body：提交代码的详细描述
footer：如果代码的提交是不兼容变更或关闭缺陷，则 Footer 必需，否则可以省略

提交类型

类型	说明
feat	特性：新功能
fix	修复：修复错误
docs	文档：文档修改（比如 README.md、CHANGELOG、CONTRIBUTE 等等）
style	格式：格式修改（不影响代码运行的变化，如空白、格式化、缺少分号等）
refactor	重构：代码重构（既不新增功能，也不是修改错误的代码变动）
perf	优化：改进性能的代码更改
test	测试：测试用例，包括单元测试、集成测试（添加缺失测试或更正现有测试）
chore	工具：构建过程或辅助工具的变动（或者增加依赖库、工具等）
revert	回滚：回滚到上一个版本
merge	代码合并
sync	同步主线或分支的 Bug

示例：

特性: 添加头像功能
特性: 添加收藏功能
修复: 在 Android 机器上传崩溃问题解决
文档: 修改 README，增加了使用说明
优化: 首页图片加载缓慢优化
重构: 对头像功能进行封装重构

格式要求

Git Commit 代码提交的标题、内容的格式要求。

# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到 issue 地址或者其它文档

辅助工具

用于约束 commit 的插件工具：

commitizen：一个格式化 commit message 的工具
commitlint：检查 commit message 是否符合常规的提交格式
conventional-changelog-cli：每次 commit 后产生 CHANGELOG 日志文件
@commitlint/config-conventional：一些常规的 commitlint 规则，如果不满足，将产生一个非零的退出代码，退出当前执行程序

辅助工具：

husky：Git Hooks

标签版本管理

项目标签版本管理的规范有多种多样，这里我们讲述的是版本语义化版本 2.0.0 的规范。

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改
次版本号：当你做了向下兼容的功能性新增
修订号：当你做了向下兼容的问题修正

先行版本号及版本编译元数据可以加到 主版本号.次版本号.修订号 的后面，作为延伸。

命名规范：

新功能开发使用第二位版本号，BUG 修复使用第三位版本号
首版本号是全新的功能类，功能模块上线才做的调整

参考

工作流

开发规范一：Git Flow + Gitlab 工作流

目录CONTENT

Git Flow规范指南