Git Flow工作流：如何更好实施代码管理
我负责的公司项目早在2014年就已经开始从SVN转向了Git，并同时启动了Git Flow代码管理方案。这几年下来，这个流程一直稳定执行，所以就做一个总结，谈谈如何更好实施Git Flow。
为何要引入Git Flow
如果代码没有一个合理的管理规范，两个人同时修改一份代码很可能会引发更加严重的问题，而且代码极其混乱，当出问题了，我们也没有办法切换到正常的分支。关于代码的管理规范，Git Flow就是一个极其合适的工作流程。
- 通过规范化的流程，使得产品、开发与测试等各个部门更高效的协同工作。
- 通过规范化的流程使得产品高效稳定运行。
Git Flow
Git Flow实际上就是分支的管理，规范我们如何更加合理地管理各个分支，避免流程出现混乱。
image.png
规范
我们的分支命名必须是严格规范，分支只有master、develop、feature/xxx、hotfix/xxx这几种，也可以增加一个release分支。
命名
- master、develop、release都是只有一个分支，而且只有管理员才拥有master、develop的权限，其他的开发者没有push 代码到这些分支。
- feature的命名是遵循
feature/功能描述，也可以增加目标版本信息feature/5.0.1/功能描述。 - hotfix的命名和feature差不多，通常只有
hotfix/4.9.0这样的命名。
说明
master
master分支只要是作为正式版本的一个备份，如果我们需要修复线上的问题，可以从master分支拉取代码进行修复。但是除以之外，我们还会有tag标签作为版本的管理。
develop
当我们在开发新功能的时候，我们都是基于
feature
通常上feature是基于develop的分支，最后也是合并到develop分支，原则是必须经过Code Review才能合并。
hotfix
当系统出现问题的时候，需要进行紧急修改的时候，就好基于master创建一个维护（hotfix）分支。原则上hotfix必须是基于master的分支。
image.png
tag 标签
标签是版本管理最重要的手段，我们每一次发布新版本，都必须在master分支打一个tag记录版本号，之后我们就可以通过tag标签找到对应版本的代码，用于回溯。
image.png
Pull Request（Merge Request）、Code Review
Pull Request，又称为 Merge Request，是 Git Flow 中非常重要的流程之一，原则上，所有的分支合并都必须走这个流程。开发者在自己的feature分支上开发功能，并且已经通过了测试，那就可以发起Pull Request请求到develop分支，代码审核员完成对代码的Code Review，如果有问题就提出建议驳回，开发者最终完成修改后再次发起合并请求。
基本原则
- 开发者的本地无需拥有master分支。
- 开发者无权对master、develop代码进行更改(不能push到master、develop)。
- 只有管理员拥有合并代码到master、develop的权限。
- 只有在功能完成后才可以请求pull request，避免单个功能进行多次pull request。
- 进行pull request前必须合并develop的最新代码到自己当前分支，同时解决冲突。
- 原则上单个任务作为最小颗粒，只能由单个程序员，若任务过大，就分拆子任务，以子任务作为最小颗粒。
