我工作的其中一个Web应用程序是一个旧的遗留系统，最近已迁移到git。该系统非常庞大。两个不同的网站运行相同的软件;但是，代码的许多部分使用简单的控制语句来执行特定于站点的事务（如果site =='this'{do custom business logic;}）。这种策略已经使用了十多年，而且变得越来越难看。
由于代码库的很大一部分在两个站点之间存在分歧，我们正在考虑分配存储库。棘手的是，大多数代码在两个系统之间合法共享。因此，如果在共享代码中修复了一个错误，那么将修复程序放入fork中似乎很棘手。例如，我们可以使用补丁。或者，我们可以在fork point创建一个分支，cherry-pick更改，然后使用pull请求。但这两种方法对我来说似乎过于复杂，我希望尽量减少复杂性。
现在回答这个问题。 这里的分叉似乎是一种好方法吗？我们应该使用分支代替，并选择共享代码的修复/增强功能吗？
顺便说一句，我会再次强调这是一个庞大的遗留系统。我们一直在努力改进系统，例如将共享的JavaScript模块拉出到自己的存储库中，并在NPM中发布这些模块。 （我们遵循Michael Feather的书中提出的准则，有效地使用遗留代码。）话虽如此，改进大型遗留系统是一个缓慢的过程。我们希望尽量减少重构，并继续进行缓慢的改进。
答案 0 :(得分：1)
您知道有大量重复代码会成为问题。最有可能的是，一旦这些网站生活在单独的回购中，他们就会发生分歧，使得交换补丁难以正确完成，而不是你最终做的事情 - 这意味着你最终会修复每个bug都有两个独立的开发工作。我无法想象基于网站ID＆＃34;与当前＆＃34;分支相关的问题。方法会比那更糟。
我理解大型系统的发展势头，但如果您选择系统方式将公共代码与不同代码分开 - 而不必担心（尚未）拆分单个通用模块，而只是首先转向3回购解决方案 - 你可以比你想象的更快到达那里。