zack-lin/blog

blog's Issues

前端代码分支管理总结

首先，你得有一个稳定迭代的项目。

通常，前端项目流程无非就是需求评审、任务拆分、研发工作量预估、代码编写、测试部署几大流程。

以下描述研发产品测试日常的某个场景：

刚开始，一个项目有4个产品同学，是的，没数错，4个。于是，不停地给你提需求，提 BUG。

某天，一个大版本开发进行中，几个产品陆续过来了，
产品 A：我想加一个加载提示；
产品 B：这里的 UI 我想换一种；
产品 C：我想去掉这几个按钮；
产品 D：需要加上几个统计；

嗯，好，都满足你们，于是，待办事项多了4个任务。

过一会，客户端研发负责人突然找我：之前定的几个 API 需要增加多几个参数；
客户端某研发同学：接口传的参数不对；
客户端测试同学：线上有几个 BUG，balabala...

嗯，好，马上改，于是，待办事项多了N个任务...
一天过去之后，今天的需求任务还没完成，待办任务还有几个没完成，只能加班了。但是这样正常吗？We need to change!

以下描述研发和产品同学日常的某个场景：
研发 A：我们在 develop 分支做迭代吧；
研发 B：提交代码的时候，我来合并代码；
过一会，
研发 A：代码合并冲突了，有几个页面，B 过来看一下。
产品同学：我们需要紧急调整需求，之前的需求放一边，开始几个紧急的需求。
研发 B：我们代码做个备份分支吧，把 develop 的回滚到之前的。
研发 A：之前 develop 分支的版本是哪个？找得回来吗？貌似 release 分支已经开始提测一部分功能了。
产品同学：...
研发同学：...

想起 Git flow 工作流，可以利用 feature 分支进行多人协作，于是，有了研发同学的改进：
研发 A：我们以后从 develop 开 feature 分支吧，然后把需求拆分到 jira 吧，每个人对应一条 feature 分支开发需求。
研发 B：嗯，我这边的是 2.1.3-1 的版本，你那边的是 2.1.3-2 的版本，就两条分支 feature/2.1.3-1 和 feature/2.1.3-2 吧
后来，
产品同学：2.1.3-1 有个需求现在先不上，要放到 2.1.4；
研发 B：oh no，我得删掉相关的代码，然后要重新测试。
研发 A：...
产品 B：...
研发 B：...
测试同学：...

放到整个前端工程化方面来看，一方面是架构处理业务隔离的能力，另一方面是仓库分支的管理，本质上是业务代码的隔离处理。
在需求拆分前期，是做业务隔离的第一步，这一步没做好，后续的工作效果也不大好。

需求拆分，应该是先隔离页面，再隔离功能，有相互联系的功能，应该一起作为一个功能点来开发，防止后续研发过程中出现业务耦合。而且，隔离的功能，必须是可以独立存在，不依赖于其他功能，使其后续可以独立测试。
研发同学工作量的预估上，是极其不靠谱的，预估多了，闲了，预估少了，加班忙死。所以产品同学需求评审完，问道：预估下工作量多少，研发同学心里特没底，只能说一个X3倍的工作量出来，这样的迭代效率肯定更低了。
所以，需求拆分另一个方面就是功能最小化，不是开发一个页面，而是开发一个图片轮换插件这样的功能点。这样，你就更能把握整个研发时间的预估，也就不会心虚。在一定的版本迭代时间内，也就可以控制研发时间的风险。
总之，需求拆分，遵循的原则就是最小化和独立化。

另一方面应该控制的，就是代码分支的拆分了，就是是按照功能特征来分配和命名还是按照研发同学的喜好呢？ 功能特征你要用什么命名？而且你得维护这样的命名对应关系，你需要花费时间思考命名的问题。

好了，说了这么多，我们还是需要一个解决方案。

1. 需求拆分到 Jira，后续的更改都在对应的 Jira 需求上登记备注，分配到每个研发同学上。（Jira 的同步信息能力在项目中的使用，这里不做讨论）
2. 在需求拆分到 Jira 之后，每一个小功能都会对应一个 ID，比如 PROJECT-280，那么代码分支也就可以对应这个分支名，如 feature/PROJECT-280，这样代码合并也就更加灵活了。研发同学可以根据版本需求，对代码进行组合提测，也就不存在需要手动删除代码的情况出现，而且每个 feature 分支都是自测通过的，保证测试质量。

在确定提测需求版本之后，合并对应分支的代码到 develop 分支，确保开发同学的 develop 分支是最新的，然后把 develop 分支的代码合并到 release 分支进行提测。

对于提测时候的 BUG 修复，
3. 测试同学在 Jira 上登记新的 ID 缺陷问题，研发同学在 bugfix 分支目录下，新建对应 ID 的分支。修复完成合并到 release 分支再全部提测。
4. 对于线上的 BUG 修复，同样，在 Jira 上做记录，研发同学在 hotfix 分支目录下，新建对应 ID 的分支。修复完成后直接提交打包测试部署。再合并到 release 分支上。
5. 部署上线之后的 release 分支代码，合并到 develop 分支，后续新版本再从 develop 创建新的分支进行迭代。

这里最核心的就是解决代码分支业务隔离的问题了。