大规模项目的Merge风险及维护的设计思路

[ghost]

看到pingcap的博文，介绍如何Merge两个巨大差异的分支。深受启发。
献丑，分享一点大规模项目的维护经验。

设计思路，通过ABI 固定式开发模式。

如果我们要增加新的引擎，按照传统方法，我们直接下手改代码了。这样的问题，是改着改着，不同的分支，差别就越来越大。Merge起来，工作量太大

另外我们还可能增加，或者删除一些API，改掉一些方法的实现。

我们先确定一个ABI版本，把这个版本的API固定了。意思就是输入，输出，行为完全 一致。在同一个ABI约束下面。我们不要去改它根本的机制。

比如我们有一个分支为BBAS_v4.0_202009B107, 这个就是它的ABI版本

我们的实现，放在了impl/BBAS_v4.0_202009B107 目录下面

我们新的分支为 BBAS_v4.1_202207B116 分支，实现位于 impl/BBAS_v4.0_202207B116 目录

当Merge之后，仓库是存在两个不重叠的不同的目录。

我们在入口main.cpp ，通过一些参数，就可以控制系统加载哪个引擎实现。

测试用例也是一样的，在各自的目录下面。

小修小改，不会bump ABI version，只有动到了引擎，我们才会bump这个version。这是计划中，已经确定的。所以不会乱来。

如果我们跨分支合并，一点痛苦都没有，井水不犯河水。各自目录发生的痛苦，不会跨ABI造成重击。

如果我们需要把功能从A，port 到B， 打开IDE 编辑器，diff 一下两个项目文件，也容易做到。 不需要用愚蠢的 git merge 功能。有时候 git merge总是射中我们的膝盖。

随着新的ABI替代掉旧的 ABI，我们逐步删除整个旧的ABI的目录。这个都是可以做计划来决定的。

核心思想：用良好的，有组织的目录。 解决单一的代码文件上的diff冲突。用显而易见的方式，管理不同的代码差异。

比如我们引擎中存在的一些驱动，都是有好多个版本的。【每一个版本都有它的功用，老的终究会被替代，但是会存在一个漫长的替代过程】

/..../storage/StorageKernelV20220719B01.java
/..../storage/StorageKernelV20220822B21.java

在同一个ABI下面，我们会换函数内部的实现，但是要求输入，输出参数一致，不会发生致命的不兼容。 也就是说你用A 版本，和B版本，看起来都是一样的。