『前端进阶』—— 代码管理方案之Git Flow

“这是我参与更文挑战的第8天，活动详情查看： 更文挑战”

前言

当你往高级前端进阶的过程中，避免不了要带领团队负责一个项目，此时你必定会遇到一个头疼的问题，代码如何进行管理。一般我们都使用Git来管理代码，业界中提供了几种Git工作流，每一种Git工作流就是一种代码管理方案，在对这几种Git工作流的流程熟悉后，才能给团队提供一种合适的代码管理方案。

本文将详细介绍其中一种Git工作流——Git Flow，希望对你有帮助，也欢迎在评论中讨论。

一、流程概念图

先上一张流程概念图，按图给你介绍Trunk-based Flow。

二、开发流程

在Git Flow是典型的双主干分支结构，其中master作为发布的主干分支，develop作为开发的主干分支。

项目刚开始时，从分支master检出分支develop，在后续的开发过程中不能用分支develop去 merge 分支master。

三、开发新功能流程

从分支develop检出feature分支来开发新功能，每当要开发一个新功能，就从分支develop检出feature分支来开发新功能。

正如 Git Flow 概念图中所述的。

Feature for future relase 未来发布功能

Major feature for next release 下一版本的主要功能

新功能可以分为未来发布功能和下一版本的主要功能，这两种新功能在merge到分支develop的时机有些差别。

下一版本的主要功能在开发过程可以不断将其feature分支合并到分支develop上，然后再把分支develop合并到feature分支上。

而未来发布功能只有再完全开发结束后，才将其feature分支合并到分支develop上。

当一个feature分支完全合并到分支develop后，要把该feature分支删除掉，保证git仓库分支的干净。

四、预发布流程

在某个时机，在分支develop上执行命令git checkout -b release，从分支develop检出预发布分支release，最好在此之前分支develop上的代码都是测试通过，且其内容是要预发布的内容，所以这个时机要把握一下。

当用分支master合并分支realse，将预发布的内容发布到正式环境后，要将分支realse删除掉。

而且预发布分支可以是多个的，那么多个预发布分支时，就不要用release来命名预发布分支，可以用要预发到正式环境的版本号来命名，如正式v1.1版本，对应预发分支r1.1。

五、修复预发布环境BUG流程

在预发布环境中出现的BUG，直接在预发布分支上修复，修复并测试通过后，要执行命令git checkout develop，切换分支develop，再执行命令git merge release，将BUG修复后的代码从预发布分支合并过来，保证开发分支develop上的代码是正确的，避免影响到下个版本。

六、发布正式环境流程

发布时，先执行命令git checkout master，切换到分支master，分支master作为发布的主干分支。只能merge其它分支，不能修改分支master的代码然后commit。

再执行命令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发布到正式环境。

在正式环境BUG都修复完成了，执行命令git checkout develop，切换到分支develop，再执行命令git merge hotfixes1.1，将BUG修复后的代码从分支hotfixes1.1合并过来，保证开发分支develop上的代码是正确的，避免影响到下个版本。最后将分支hotfixes1.1删除掉。