多个网站，单个代码库：git fork？

我工作的一个Web应用程序是一个旧的遗留系统，最近已经迁移到git。该系统相当庞大。两个不同的网站运行这个相同的软件;然而，代码的很多部分使用简单的控制语句（如果site =='this'{do custom business logic;}）来执行特定于站点的事情。这个策略已经使用了十多年了，而且越来越难看了。多个网站，单个代码库：git fork？

由于代码库的很大一部分已经在两个站点之间分歧，我们正在考虑分叉库。棘手的是，大部分代码在两个系统之间合法共享。因此，如果在共享代码中修复了一个错误，那么修复进入分支似乎会非常棘手。例如，我们可以使用补丁。或者，我们可以在叉点创建分支，挑选更改，然后使用拉取请求。但是这两种方法对我来说都过于复杂，我想尽量减少复杂性。

现在的问题。 分叉似乎是一个很好的方法吗？我们是否应该使用分支机构，然后选择修复/增强共享代码？

另外，我会再次强调这是一个很大的遗留系统。我们一直致力于改进系统，将共享JavaScript模块放入自己的存储库并在NPM中发布这些模块。（我们正在遵循Michael Feather的书中提出的指导原则，与遗产代码有效地合作）。这就是说，改进大型遗留系统是一个缓慢的过程。我们希望尽量减少重构，并不断进行缓慢的改进。

来源

2017-09-22 avejidah

你提出的只是另一个版本的“越来越难看”的方法，你已经有了。它并不能真正解决问题，它只会让别的东西变得丑陋。相反，我会建议一些重构。从代码库中提取共享代码，并有两个引用共享代码的独立应用程序，或者从代码库中提取不同的代码，并有一个应用程序根据某些应用程序配置动态加载特定于站点的库。 – David

谢谢@戴维。我真的很同意这一点，这是我们迄今为止选择的方式（例如通过将共享代码移动到npm模块）。但重构需要的时间很长，因为我们有破解经过时间检验的代码的风险。我真的很想使用一个工具（git here）来帮助缓慢，安全和精心策划的重构工作。我们希望保持一个系统完好无损，只需更换其他系统，但当然会传播任何修复程序。但是，也许，如你所说，这不是一条好路径。无论如何，感谢您的评论。 – avejidah

这确实是一个标准的商业问题。技术债务多年来一直在积累，团队一起决定“以后再处理”。欢迎来到以后:)在这一点上的选择是承担成本并纠正现在的问题，或者增加更多的技术债务，并在以后以更高的成本“处理它”。这两种方法都是有效的方法，取决于风险和成本的权衡。 – David

你知道有大量的重复代码将成为一个问题。很有可能一旦这些网站存在于不同的回购站中，它们会以不同的方式交换补丁，难以正确完成，这不是最终的结果 - 这意味着您最终会通过两项独立的开发工作来修复每个缺陷。我无法想象与目前“基于站点ID的分支”方法相关的问题会比这更糟糕。我知道一个大系统的势头，但如果你选择一个系统的方式来分离普通代码和发散代码 - 而不必担心（但是）分裂各个公共模块，而只是朝着3 -repo解决方案 - 你可以比你想象的更快。

来源

2017-09-22 17:27:34

Mark：谢谢你的回应，但你能澄清几点吗？ 1）当你说“基于站点ID的分支”你的意思是代码分支，对吧？（而不是VCS。）2）当您说3回购解决方案时，您是否建议使用通用代码的回购协议，然后两个分支（每个站点一个）？我们正在寻找一种随时间会持续下去的系统性方法，我们不希望加剧目前的问题或在这里采取捷径。由于我们试图分解代码的一部分，因此我们需要一种可以理解，具有成本效益的方法，并随着时间的推移缓慢地改进系统。 – avejidah

1）是的，我指的是代码中的逻辑分支。我的意思是说，跟你现在的情况一样糟糕，简单分支中涉及的通用代码问题更糟。 –

2）3-repo解决方案可以将常用代码保存在一个回购站中，站点1代码存储在一个回购站中，而站点2代码存储在一个回购站中。我不会使用任何叉子去解决这个问题。 –

多个网站，单个代码库：git fork？

回答

相关问题