业界代码评审模型：PR(Pull request): 来自于Github开源社区，先Fork（复制）代码库，自己另起炉灶，然后向对方发PR贡献；只适合开源场景，对企业代码管理是噩梦。MR（Merge request): 分支合并请求，来源于PR；分支级评审粒度较粗、滞后、不适合企业研发场景；需要登录Web界面，效率低；企业内部开源协同需要有分支权限，不适合企业内开源协同场景。CR（Change request): Google，极客范，用户体验太差，需要用特殊命令，每次只能评审一个commit；某友商改造后可以评审多个commit后，导致同一评审会出现多个不同id，用户懵圈。DCR（Direct code review）：客户端可直接发起评审，使用效率高；直接支持commit粒度评审，评审粒度小，契合企业研发场景；无需任何特殊语法；可评审多个commit，操作极简；完美支持DCR+MR双模型；唯一契合企业内开源协同。ezCode唯一同时支持MR、CR、DCR, 集成了优点，去除了缺点。DCR唯一契合企业内开源协同场景：更安全：无需向企业所有成员开放代码写或者分支权限；更规范：贡献者无需Fork代码，避免企业代码大量重复；更方便：贡献者无需自己搭建流水线，直接DCR向公开库发起代码评审。

DCR + MR 完美支持企业开发场景、提交即评审、入库即卡位、预知潜在问题，开发：DCR至远端Dev分支 提测：Dev分支-QA分支 MR 上线：QA分支-Master MR。

分支冲突前置预警专利技术，软件工程中多分支开发的经典问题---代码冲突。冲突发现越早，解决成本越低。