前言
Git 的名称太响了，相信大家都听说过，鼎鼎大名的同性交友网站 GitHub 就是基于 Git 作为唯一的版本库格式进行托管的平台。本篇不详细介绍 Git 的使用，仅介绍基于 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分支，解决冲突。 - 正常的开发流程。
参考
Git版本管理规范(Git Flow)
产品快速迭代时用Git做分支管理的详细步骤
