“这是我参与更文挑战的第7天，活动详情查看： 更文挑战”
前言
当你往高级前端进阶的过程中，避免不了要带领团队负责一个项目，此时你必定会遇到一个头疼的问题，代码如何进行管理。一般我们都使用Git来管理代码，业界中提供了几种Git工作流，每一种Git工作流就是一种代码管理方案，在对这几种Git工作流的流程熟悉后，才能给团队提供一种合适的代码管理方案。
本文将详细介绍其中一种Git工作流——Trunk-based Flow，希望对你有帮助，也欢迎在评论中讨论。
一、流程概念图
先上一张流程概念图，按图给你介绍Trunk-based Flow。
二、开发流程
Trunk-based Flow 中开发者只能在trunk分支上开发代码，不得检出其它分支开发。
因为本地和trunk分支之间不存在一个缓存的区域，所以每次从本地commit到trunk分支前，要先在本地build，并测试没问题后才能commit。
图中的绿色方框的C表示每个成员的提交。
三、测试流程
用Trunk-based Flow的方式来管理代码，目标是持续集成和持续交付。所以trunk分支即作为开发分支也作为测试分支，要求开发者在24小时中至少要本地build一次，并本地测试通过后commit到trunk分支，将trunk分支的代码部署到测试环境，进行测试，测试中出现BUG，直接在trunk分支上修复，并commit到trunk分支，再部署到测试环境。这样持续集成，确保trunk分支的代码随时可以按需发布，才能做到持续交付。
四、预发布流程
当产品要求预发布一个版本时，可以执行命令git checkout commitId -b 1.1.x，用trunk分支中某个commitId来检出一个预发布分支1.1.x，其中1.1.x是分支名，分支名以大版本号命名，例如1.1版本，分支命名为1.1.x。
图中的黑色方框的B表示以上操作。
五、修复预发布环境BUG的流程
发布分支的代码测试出BUG时，还是在trunk分支上修改，修复完成，commit到trunk分支，测试通过后。
将修复BUG的代码提交到预发布分支时，要先执行命令git checkout 1.1.x，然后执行命令git cherry-pick commitId，其中commitId是修复BUG的代码commit到trunk分支的commitId。
图中的红色方框的C和灰色方框的M表示以上操作。
开发负责人在预发布分支的本地build后，并测试通过，然后才能执行commit提交到发布分支上。
图中的蓝绿色方框的C表示以上操作。
六、发布正式环境流程
例如要发布1.1.x版本到正式环境，要在预发布分支1.1.x上，执行命令git tag -a 1.1.1 commitId -m “发布1.1.1版本，打一个tag出来，将这个tag发布到正式环境。
图中的紫色方框的R表示以上操作。
七、修复正式环境BUG的流程
修复正式环境BUG的流程和修复预发布环境BUG的流程一致，但是流程的最后有点不同。
在正式环境BUG修复并测试通过后，要执行命令git tag -a 1.1.2 commitId -m “发布1.1.2版本，打一个tag出来，将这个tag发布到正式环境。
八、大版本迭代流程
当大版本迭代时，比如要从1.1版本迭代到2.1版本时，可以在trunk分支上执行命令git checkout commitId -b 2.1.x，用trunk分支中某个commitId来检出一个预发布分支2.1.x。
图中的黑色方框的B表示以上操作。
