这让我想起了我以前的工作。似乎，在我加入之前，所有东西都在一个巨大的文件中(也是c++)。然后他们将其拆分(在完全随机的点上使用include)为大约三个(仍然是巨大的文件)。正如你所预料的那样，这个软件的质量非常糟糕。该项目总标线约为40k。(几乎没有注释，但有大量重复代码)

最后，我完全重写了这个项目。我从头开始重做项目中最糟糕的部分。当然，我想到了这个新部分和其他部分之间可能的(小)接口。然后我把这个部分插入到旧的项目中。我没有重构旧代码来创建必要的接口，只是替换了它。然后我从那里迈出了一小步，重写了旧代码。

我不得不说，这花了大约半年的时间，在此期间，除了修复错误之外，没有开发旧的代码库。

编辑:

它的大小保持在40k LOC左右，但与8年前的软件相比，新应用程序在初始版本中包含了更多的功能，可能bug也更少。重写的一个原因是我们需要新的特性，而在旧代码中引入这些特性几乎是不可能的。

该软件是为一个嵌入式系统，一个标签打印机。

我应该补充的另一点是，理论上这个项目是c++的。但它根本不是面向对象的，它可能是c。新版本是面向对象的。

我猜一下，如果这段代码为10个客户服务，并且包含代码变体，那么您可能有很多针对特定客户的带有变体的代码克隆

我很想对你的11000行文件进行克隆检测。(事实上，如果你把它发给我，我会用我的c++克隆检测器[见生物]，并把答案发给你)。

这将显示任何克隆，以及这些克隆是如何变化的。有了这些信息，重构代码就变得相当容易了。

下面是我所想到的解决这些问题的唯一办法。所述方法的实际增益是演化的累进性。这里没有革命，否则你很快就会陷入麻烦。

在原来的主类上面插入一个新的cpp类。目前，它基本上会将所有调用重定向到当前的主类，但目标是使这个新类的API尽可能清晰和简洁。

一旦完成了这些，就可以在新类中添加新功能。

至于现有的功能，当它们变得足够稳定时，您必须逐步将它们移动到新的类中。对于这段代码，您将失去SCC帮助，但是对此没有太多办法。只要选择合适的时机。

我知道这并不完美，但我希望它能有所帮助，这个过程必须适应您的需要!

额外的信息

注意，Git是一个SCC，它可以从一个文件跟踪代码片段到另一个文件。我听说过关于它的好东西，所以它可以帮助你逐步转移你的工作。

Git是围绕blob的概念构建的，如果我理解正确的话，blob表示代码文件的片段。在不同的文件中移动这些片段，Git会找到它们，即使您修改了它们。除了下面评论中提到的Linus Torvalds的视频之外，我还没有找到关于这个问题的一些清楚的东西。

考虑以更合理的方式重写整个应用程序的方法。也许可以重写其中的一小部分作为原型，看看你的想法是否可行。

如果您已经确定了一个可行的解决方案，那么相应地重构应用程序。

如果所有产生更合理架构的尝试都失败了，那么至少您知道解决方案可能是重新定义程序的功能。

永远不要再碰这个文件和代码! 对待就像你被困住了一样。开始为编码在那里的功能编写适配器。 用不同的单元编写新代码，只与封装怪物功能的适配器对话。 ．.． 如果以上只有一项是不可能的，那就辞职去找一份新工作。

Find some code in the file which is relatively stable (not changing fast, and doesn't vary much between branches) and could stand as an independent unit. Move this into its own file, and for that matter into its own class, in all branches. Because it's stable, this won't cause (many) "awkward" merges that have to be applied to a different file from the one they were originally made on, when you merge the change from one branch to another. Repeat. Find some code in the file which basically only applies to a small number of branches, and could stand alone. Doesn't matter whether it's changing fast or not, because of the small number of branches. Move this into its own classes and files. Repeat.

因此，我们去掉了到处都一样的代码，以及特定于某些分支的代码。

This leaves you with a nucleus of badly-managed code - it's needed everywhere, but it's different in every branch (and/or it changes constantly so that some branches are running behind others), and yet it's in a single file that you're unsuccessfully trying to merge between branches. Stop doing that. Branch the file permanently, perhaps by renaming it in each branch. It's not "main" any more, it's "main for configuration X". OK, so you lose the ability to apply the same change to multiple branches by merging, but this is in any case the core of code where merging doesn't work very well. If you're having to manually manage the merges anyway to deal with conflicts, then it's no loss to manually apply them independently on each branch.

我认为你说这种SCC无关紧要是错误的，因为例如git的合并能力可能比你正在使用的合并工具更好。因此，核心问题“合并困难”发生在不同scc的不同时期。但是，您不太可能更改scc，因此这个问题可能无关紧要。