布景
代码diff体系，是增量静态代码扫描，增量代码覆盖率，增量接口扫描等很多基础体系的依赖方，其安稳性和功能直接影响整个工作流。随着调用量的升高，尤其是转转增量代码计算率功能成为beetle流程中的卡点，代码diff作为基础数据提供方，渐渐暴露出了功能和前期设计计划的问题。
原始完成计划的流程如下图：
存在问题
1、需求将gitlab上的代码分支克隆到本地服务器（分支新建时提早预热），通过jgit的接口进行diff。可是当代码仓库比较大，在上面提到的反常流程时，依然要clone，拉取时刻长，影响接口功能。
2、在本地服务器diff，需求加锁，导致不支持同一个代码仓库的并发。
优化计划
1、空间换时刻
依然运用代码clone到本地的计划，可是依照分支维度放置代码。这样能解决不同分支间的并发问题。长处：去除了本地git锁判别过程，逻辑相对于本来改动小，完成成本小。缺乏：相同分支的情况下，依然需求在平台上对jgit的代码处理逻辑加锁。锁抵触的概率和代码git pull的时刻成正比。并发较高的情况下，失败和等候的时刻依然不可接受。
2、去掉jgit
运用东西java-gitlab-api，调用gitlab原生的api获取diff的差异，并发和功能都很安稳，咱们采用了这个新计划。上线初期阶段表现是完全符合要求的，也在想之前的搭档为什么没有采用这个计划？
新的问题
运用过程中调用方反应，diff禁绝（gitlab原生接口还禁绝？）。通过排查发现，gitlab的接口没有忽略空格的选项。而jgit能够运用WS_IGNORE_ALL等参数，略掉空格等格局的改变。业务方需求忽略掉仅仅改变了空格和格局的内容。这样增量计算才准。
计划补：
通过一番调研之后，咱们发现gitlab的diff接口是没有额定的参数的。所以咱们决定在gitlab的diff成果上，增加一个对比补偿计划。而且期望处理成果尽量和jgit处理成果共同。通过调研和多次测验，最终确认运用开源东西java-diff-utils对gitlab回来的数据格局进行预处理，同时运用和jgit同样的diff算法HistogramDiff来确保数据的共同性。
其他问题：
1、运用过程中发现部分大文件获取差异内容为diff为空。原因是触发了Gitlab Diff数据大小约束。参阅 Diff limits administration | GitLab 修正。
2、上面的计划，在diff文件量很大的时分，会触发功能问题，运用多线程处理。
总结
在运用gitlab api的计划过程中，咱们进行了很多的测验，走了很多的弯路，最终到达现在的效果。确保作为基础中的基础体系－－diff体系的安稳和功能。各位朋友如果有其他的计划和思路欢迎在评论区留言，咱们一同交流下。
参阅资料
1，https://github.com/java-diff-utils/java-diff-utils
2，https://docs.gitlab.com/ee/api/
作者：王悦
转转研发中心及业界小伙伴们的技能学习交流平台，定期分享一线的实战经验及业界前沿的技能话题。
重视大众号「转转技能」（综合性）、「大转转FE」（专心于FE）、「转转QA」（专心于QA），更多干货实践，欢迎交流分享~
