前言
当你往高级前端进阶的过程中，避免不了要带领团队负责一个项目，此时你必定会遇到一个头疼的问题，代码如何进行管理。一般我们都使用Git来管理代码，业界中提供了几种Git工作流，每一种Git工作流就是一种代码管理方案，在对这几种Git工作流的流程熟悉后，才能给团队提供一种合适的代码管理方案。
本文将详细介绍其中一种Git工作流——Aone Flow，希望对你有帮助，也欢迎在评论中讨论。
一、开发流程
在Aone Flow中只有三种分支，正式分支master，预发布分支release，功能分支(特性分支)feature。
当开发新功能时，从master分支创建feature分支，分支的命名通常以“feature/功能名称”来命名，每个feature分支可以是一个人完成，或是多个人协作完成。
切记不能用master分支去合并feature分支，也不能在master分支上直接修改代码然后提交，master分支只能用来合并release分支。
二、预发布流程
在Aone Flow中使用release分支作为预发布分支，先用master分支创建一个release分支，分支的名称通常以release/环境名称，然后将要预发布的功能对应的feature分支合并到release分支。最后将release分支的代码部署到对应的预发布环境进行测试，若出现BUG，直接在release分支上修复，修复完成后再部署到对应的预发布环境测试。
三、正式发布流程
当release分支的代码在对应的预发布环境测试通过后，用master分支合并release分支，合并完成后打出一个tag，其tag的名称可以用版本号来命名，然后将tag上的代码部署到正式环境，正式发布流程完成，同时删除release分支和相关联的feature分支。
四、修复正式环境的BUG流程
若正式环境出现BUG，那么要找到对应版本的tag，用tag创建出一个release分支，此时的release分支相当fixbug分支，在release分支上修复BUG后，将代码部署到对应的预发布环境进行测试。
若测试通过后，在release分支打一个tag，其tag的名字用该版本号后面加个小版本号来命名，如修复v1.1版本的BUG，则tag的名称为v1.1.1，然后将该tag的代码部署在正式环境，最后再用master分支合并release分支，合并完成后将release分支删除。
若测试未通过，继续在release分支修复BUG，再将代码部署到对应的预发布环境进行测试。
