前言
本篇不详细介绍 Git 的使用，仅介绍基于 Git 的开发分支流程规范。
简述
Git 管理中，最重要的一个点就在于分支的管理。在项目开发中，一般涉及到 Git 的相关分支有：
master/main: 主分支，版本正式发布的代码都用这个分支的代码进行编译，常设置为受保护的分支。
dev/develop: 开发分支，开发环境基于此分支进行构建。
feature-: 开发某个特定功能的分支。
hotfix-/fix-: bug 修复分支。
release-: 测试平台用。
对于比较小型的项目，参与人较少时，可以仅保留 master, develop 分支。
这里只是一个常规的项目的分支管理，仅作借鉴，具体情况需具体分析。
实际情况
本人目前开发一个项目，代码是由我一个人写的，在进行短期迭代中。
每天就是基于 develop 分支进行代码编写，功能写完后直接提交至 develop 分支进行测试环境的搭建，提交测试，有问题了直接修改提交至 develop 分支，即 develop 分支上的代码就是测试环境所用的代码
迭代结束，将 develop 分支合并至 master， 并打上正式版的 tag。
开发流程
- 从 develop 分支拉出一个新分支（feature-/fix-）。
- 开发完成，提交分支至远程仓库。
- 创建合并请求（merge request，feature-* -> develop），请求项目管理人去进行代码审查并合并分支至 develop。
- 测试通过后，将 develop 分支合并至 master 分支，并打上相应的 tag，一般为正式版本号。
项目每一个版本，都会重复上述流程。
问题 && 解决
迭代过程中（1.1），发现了上一个正式版（1.0）发布，有重大的 bug 需要修复，比较紧急，但是当前 develop 分支更改了很多 1.1 版本的功能，还没有测试完成，不能直接根据当前的 develop 分支进行修改。
还好之前发布 1.0 版本时将当时 develop 分支的代码合并到了 master 分支，现在只需要从 master 分支上拉取代码进行修改，再将修改的内容合并到 master 进行发布即可。这里要注意之后再开发 develop 分支的时候，要先拉取一下 master 的代码进行合并，有冲突就修改，保证下次从 develop 分支再合并到 master 的时候不会有冲突。
总结
- Git 的流程设计还是很棒的，熟悉了之后是可以方便的进行联合开发工作，建议多花些时间了解。
- 对于不同规模，不同场景下的项目，Git 的工作流是可以自行更改优化的，最终的目的就是方便、快速、准确的构建项目体系。
本篇主要讲述了一个迭代过程中，突遇线上紧急 bug 需要修复时的 git 工作流的设计，即保证线上的环境用的始终是 master 分支的代码：
- 从 master 检出新的分支并进行修改。
- 将修改后的代码合并到 master 分支，并编译发布，打 tag。
- 将修改后的 master 分支合并到当前开发的 develop 分支，解决冲突。
- 正常的开发流程。