[开发工具]git 迭代开发分支流程规范

前言

Git 的名称太响了，相信大家都听说过，鼎鼎大名的同性交友网站 GitHub 就是基于 Git 作为唯一的版本库格式进行托管的平台。本篇不详细介绍 Git 的使用，仅介绍基于 Git 的开发分支流程规范，需要对 Git有一定的了解。

简述

Git 管理中，最重要的一个点就在于分支的管理。在项目开发中，一般涉及到 Git 的相关分支有：

1. master/main: 主分支，版本正式发布的代码都用这个分支的代码进行编译，常设置为受保护的分支。
2. dev/develop: 开发分支，开发环境基于此分支进行构建。
3. feature-*: 开发某个特定功能的分支。
4. hotfix-/fix-: bug 修复分支。
5. release-*: 测试平台用。

对于比较小型的项目，参与人较少时，可以仅保留 master, develop 分支。

这里只是一个常规的项目的分支管理，仅作借鉴，具体情况需具体分析。

实际情况

本人目前开发一个项目，代码是由我一个人写的，在进行短期迭代中。

每天就是基于 develop 分支进行代码编写，功能写完后直接提交至 develop 分支进行测试环境的搭建，提交测试，有问题了直接修改提交至 develop 分支，即 develop 分支上的代码就是测试环境所用的代码。

迭代结束，将 develop 分支合并至 master， 并打上正式版的 tag。

开发流程

1. 从 develop 分支拉出一个新分支（feature-*/fix-*）。
2. 开发完成，提交分支至远程仓库。
3. 创建合并请求（merge request，feature-* -> develop），请求项目管理人去进行代码审查并合并分支至 develop。
4. 测试通过后，将 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 分支的代码：

1. 从 master 检出新的分支并进行修改。
2. 将修改后的代码合并到 master 分支，并编译发布，打 tag。
3. 将修改后的 master 分支合并到当前开发的 develop 分支，解决冲突。
4. 正常的开发流程。

参考

Git版本管理规范(Git Flow)
产品快速迭代时用Git做分支管理的详细步骤