“这是我参与更文挑战的第8天，活动详情查看： 更文挑战”
前言
当你往高级前端进阶的过程中，避免不了要带领团队负责一个项目，此时你必定会遇到一个头疼的问题，代码如何进行管理。一般我们都使用Git来管理代码，业界中提供了几种Git工作流，每一种Git工作流就是一种代码管理方案，在对这几种Git工作流的流程熟悉后，才能给团队提供一种合适的代码管理方案。
本文将详细介绍其中一种Git工作流——Git Flow，希望对你有帮助，也欢迎在评论中讨论。
一、流程概念图
先上一张流程概念图，按图给你介绍Git Flow。
二、开发流程
在Git Flow是典型的双主干分支结构，其中master作为发布的主干分支，develop作为开发的主干分支。
项目刚开始时，从master分支检出develop分支，在后续的开发过程中不能用develop分支去合并master分支。
开发新功能时，要用develop分支检出feature分支来开发新功能，每当要开发一个新功能，就从develop分支检出feature分支来开发新功能。
正如 Git Flow 概念图中所述的：
Feature for future relase 未来发布功能
Major feature for next release 下一版本的主要功能
新功能可以分为未来发布功能和下一版本的主要功能，这两种新功能在合并到develop分支的时机有些差别。
下一版本的主要功能在开发过程可以不断将其feature分支合并到develop分支上，然后再把develop分支合并到feature分支上。
而未来发布功能只有再完全开发结束后，才将其feature分支合并到develop分支上。
当一个feature分支完全合并到develop分支后，要把该feature分支删除掉，保证git仓库分支的干净。
三、测试流程
develop分支作为测试分支，将develop分支的代码部署到测试环境，当测试出BUG后，直接在develop分支上修复BUG，修复完成后，再将develop分支的代码部署到测试环境进行测试。
四、预发布流程
在某个时机，在develop分支上执行命令git checkout -b release，从develop分支检出预发布分支release，最好在此之前develop分支上的代码都是测试通过，且其内容是要预发布的内容，所以这个时机要把握一下。
如流程概念图中所描述的：
From this point on, 'next relase' means the release after 1.0 从这一点上说，“next relase”是指1.0之后的版本
Statr of release branch for 1.0 发布分支1.0的状态
当用master分支合并realse分支，将预发布的内容发布到正式环境后，要将realse分支删除掉。
而且预发布分支可以是多个的，那么多个预发布分支时，就不要用release来命名预发布分支，可以用要预发到正式环境的版本号来命名，如正式v1.1版本，对应预发分支r1.1。
五、修复预发布环境BUG流程
在预发布环境中出现的BUG，直接在预发布分支上修复。
如流程概念图中所描述的：
Only bugfixes! 只有错误修正！
修复并测试通过后，要执行命令git checkout develop，切换到develop分支，再执行命令git merge release，将BUG修复后的代码从预发布分支合并过来，保证develop分支上的代码是正确的，避免影响到下个版本。
如流程概念图中所描述的：
Bugfixes from rel.branch may be conitnuously merged back info develop 来自release分支的错误修复会被合并到develope分支
六、发布正式环境流程
发布时，先执行命令git checkout master，切换到master分支，master分支作为发布的主干分支。只能合并其它分支，不能修改master分支的代码然后提交。
再执行命令git merge release，合并预发布分支。最后执行命令git tag -a 1.1 -m “发布1.1版本″，打一个tag出来，将这个tag发布到正式环境。
七、修复正式环境BUG流程
正式环境出现BUG时，要在master分支上执行git checkout -b hotfixes1.1，检出hotfixes1.1分支来修复BUG，其中1.1表示正式线1.1版本发现BUG需要修复。
修复完成并测试通过后，先执行命令git checkout master切换到master分支，再执行命令git merge hotfixes1.1合并hotfixes1.1分支，执行命令git tag -a 1.2 -m “发布1.2版本，再打一个tag出来，将这个tag发布到正式环境。
如流程概念图中所描述的：
Severe bug fixed for production: hotfix 0.2 已修复用于生产的严重错误：修补程序0.2
在正式环境BUG都修复完成了，执行命令git checkout develop，切换到develop分支，再执行命令git merge hotfixes1.1，将BUG修复后的代码从hotfixes1.1分支合并过来，保证develop分支上的代码是正确的，避免影响到下个版本。最后将hotfixes1.1分支删除掉。
如流程概念图中所描述的：
Incorporate bugfix in develop 在开发中加入错误修复
