『前端进阶』—— 代码管理方案之Trunk-based Flow

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

前言

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

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

一、流程概念图

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

二、开发流程

Trunk-based Flow 中只有一条开发分支trunk，开发者只能在开发分支trunk上开发代码，不得检出其它分支开发。

因为本地和开发分支trunk之间不存在一个缓存的区域，所以每次从本地commit到开发分支trunk前，要先在本地build，并测试没问题后才能commit。

图中的绿色方框的C表示每个成员的提交。

三、预发布流程

用Trunk-based Flow的方式来管理代码，目标是持续集成和持续交付。所以要求开发者在24小时中至少要本地build一次，并测试完成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表示以上操作。