前端和服务端大仓库主干开发理念差异

前端功能：可少不可多

前端是用户行为的起点，如果用户没有发起操作，那么到服务端的整个链路不会建立。

前端是可以缺少功能的，因为即使功能本应存在，但是不小心的丢失，也是可以被用户自行解释的：被阉割、兼容性、维护等等。

如果前端正在开发过程中的代码不小心上了线，但是此时服务端还没有准备好，链路途中会遇到阻碍，这是不能接受的，因为从用户角度看，这种情况是无法自行解释的：系统出错、难用、土豆服务器等等。
现实情况中，前端的单元测试和端到端测试，大多数公司都是缺失的。即使有，也不能做到完备，毕竟前端更多的关注的是视觉效果，这种很难用代码进行测试。

同时，我们在增加一个新功能的时候，很可能会意外地更改了本不该改动的部分，比如全局 css 样式，公共模块等等。这些修改，也很难被自动化测试和人工进行检验。

尤其是在前端大仓库条件下，如果采用了主干开发，也就是谷歌的模式，最新的稳定代码，随时可以上线，通过特性开关控制功能是否开放给用户。在团队不具备谷歌一样完备的验证系统的前提下，那么很可能会导致还在研发的代码，影响到特性以外的部分，尤其是展示。

因此，从目前我的理解来看，前端大仓库，是不适合使用主干开发模式进行研发的。

我不是说前端不适合使用大仓库，而是不适合使用主干开发，或者目前的分支模型，还需要对前端进行调整。而且，我们依然可以用其他分支模型来配合大仓库。

服务端功能：可多不可少

服务端恰恰相反，大多数服务端逻辑，是面向接口的，在良好设计的前提下，接口之间的逻辑很少相互影响，在增加一个新特性的时候，往往通过冗余，能够保证前后兼容。同时服务端又可以用单元测试完成大多数主要的功能测试，保证稳定输出，检测错误提交，在主干分支进行持续集成。

所以服务端就很适合使用主干分支进行研发，通过特性开关来控制是否可以被访问。只要前端没有开放入口，那么用户就不会建立任何向新特性的访问。

总结

服务端功能可多不可少，更适合用主干开发。

前端功能可少不可多，不适合主干开发。