Git分支管理背景
Git
是当下最流行的版本管理系统，阮一峰在自己的博文中提到过：“如果你严肃对待编程，就必定会使用版本管理工具”。
Git
操作是基于分支的，当下环境衍生出多种优秀的分支管理策略，其目的就是要保证不同分支各司其职，避免多人协作过程中代码冲突、代码版本出现问题。在日常迭代过程中，每个公司都有一套自己的分支管理规范，但万变不离其宗，都有
Vincent Driessen
提出的
Git flow
方法的影子。
Git flow关键分支
基于
Git flow
方法协作提交代码时，一般是基于一下分支：
| 分支名称 | 分支说明 | 分支时效 | 环境 |
|---|---|---|---|
| master | 与线上环境运行代码版本一致，需保证最高稳定性 | 主分支 | 线上生产环境 |
| develop | 开发过程中成员操作分支（前后端对接调试阶段） | 主分支 | 开发环境 |
| feature | 新功能分支，一般一个新功能对应一个分支，以避免后面一些不必要的代码冲突 | 临时分支 | |
| release |
亦或者叫分支，修复测试环境Bug所用分支，建议一个Bug单独切一个分支，(测试阶段) |
实施分支 | 测试环境/压测环境/预生产环境 |
| hotfix | 紧急修复线上BUG的时候使用的分支 | 临时分支 |
以下是
Git flow
流程图：
master与develop
这张图涉及内容较多，我们只需要关注两个分支，一个是
master
分支，另一个是
develop
分支，通过箭头可以看到，
develop
分支是基于
master
分支创建，在提交代码后，又重新回到了
master
分支，这里体现的是，在迭代开始前，需要基于线上代码最新版本合并到开发分支，作为团队成员开发的公共分支。在使用
Git
时，需要遵循一个原则：
从哪里来，最后回到哪里去
。
develop与feature
接下来我们需要关注的是
feature
分支与
develop
分支。在团队协作过程中，对于需求的开发，通常是采用一个成员负责一个功能点或者模块，那么就需要不同成员往
develop
分支提交代码，即需要从
develop
分支创建
feature
分支开发新功能，编码自测完成后，再从
feature
分支push（推送）到
develop
分支，这同样遵循了以上规则。
develop与release
在企业开发中，每次迭代往往定义一个版本号，
release
分支与之对应。随时间线推进，到达迭代开发中的提测阶段，则需要将开发的新代码从
develop
分支推送到
release
分支，而后发布代码(CI/CD)到测试环境供测试验证。
release与bugfix
当测试提出缺陷时，似乎我们需要排查一下自己代码中是否存在问题。如果是，那么我们需要基于测试环境的
release
分支代码版本做修改，此时，我建议基于
release
分支去创建一个
bugfix
分支用于修复代码中的问题。修复完毕后再将
bugfix
分支的代码推送到
release
分支，push完成后，将
bugfix
分支删除，
确保一个
bugfix
分支只做一件事
。
注意：
在合并前需要确保
release
分支代码是最新版本，建议
在push到其他分支前update一下分支到最新版本
，因为不止你一个可怜人在修复Bug。
如果你所在的公司使用
Git flow
的标准流程。
develop
分支承担了两个“角色”：“写Bug”和“改Bug”。则同样可以从
release
分支更新最新代码后，将
release
分支代码
merge
(合并)到
develop
分支。再基于
develop
分支修改代码，push到
develop
，而后切换到
release
分支，更新到最新版本，merge
develop
分支到
release
分支即可。
release与master
测试完成、熬到上线、喜大普奔。上线时需要将
release
分支代码推送到
master
，同样的道理，在推送前需要将
master
分支代码更新到最新版本，
release
分支合并
master
分支代码，再切换到
master
分支合并
release
分支代码。
上线时需要整理迭代涉及的配置项更新、迭代变更
SQL
脚本、历史数据处理数据
SQL
脚本、静态资源等整理出来，发布执行到线上环境，此过程不在本文中赘述。
master与hotfix
紧急！震惊！线上代码失去公信力了吗？
当生产环境用户反馈了一个问题，确认为代码缺陷时，需要基于最新的
master
分支创建
hotfix
分支去修复线上bug，修复完毕后，从
hotfix
分支按上述
release
分支推送到
master
分支流程推送代码到
master
分支即可。
为什么在merge其他分支前，需保证其他分支代码为最新版本？
你并不能确定目标分支代码是否有变更。
- 一个工程可能有多个团队维护、推送代码，你并不知道其他团队什么时间、推送了什么内容到分支。
- 在不同迭代版本时间线上，可能有一些线上bug的维护。
如何使用Git flow
- 命令行
- 编码工具自带Git客户端，如IDEA
- sourceTree
- …
最后
提高团队协作效率，人人有责。