代码库最佳实践

Question

我在一家为各种客户进行大量定制开发的公司工作。有些项目是独一无二的，但其中许多项目也使用我们多年来开发的一套通用代码。这种模式长期以来运行良好。但是我们目前正在从SVN转向Mercurial（hg），所以我正在思考如何设置不同的存储库。

现在我们有一个回购我们的内部工作。这些项目的范围从日志等基本实用程序到内部使用的自定义应用程序。而且它还有很多旧代码没有被主动更新，但随时可以保留一些旧的旧代码需要修改。

对于每个客户，我们制作一个单独的回购，并将其所有代码放入专用回购。 关于这个结构的好处是，如果你想处理客户端的代码，你只需从他们的回购中获得一切，再加上“核心”内部代码，并且你拥有了你所需要的一切。一个缺点是客户端代码可能变得陈旧，甚至与我们核心代码的变化不同步。

但我想听听其他人的做法。有许多客户特定的存储库和一个相当大的内部存储库是否有意义？一些客户的代码量很大，而其他客户的代码量非常小。是否有意义为每个回购？

此外 - 我们把所有客户端工件放入每个客户端存储库。这不仅包括源代码，还包括规范，合同，签名的PDF，Excel，Visio，Word和其他文档。这对我来说似乎很浪费，而且我正在思考从真实代码中分离出工件。别人如何处理这些事情？

Answer 1

你可以做到以下几点：

• 把核心代码在一个中央存储库
• 把客户端代码在客户特定的仓库
• 做的核心代码不放直接拷贝在客户端存储库中，而不是包含核心代码存储库作为subrepository

这给你b效益，你仍然可以只是拉客户端存储库，并得到客户端的东西和的核心代码。
此外，子库会自动指向核心代码库的某个版本，如果您需要更新的版本，则必须进行显式更新。因此，如果在此期间更新了核心代码库，则客户端存储库中的子库会自动获取这些更改（这可能会破坏您的客户端代码），而不是而不是。

Answer 2

如果您为与您的核心产品代码相互作用的客户开发了自定义代码，则应该在每次核心更新时对其进行审核，以确保它不会“与我们的核心代码的变化不同步”。无论您是收取维护费还是单独进行审查和维护，这都是有利可图的。更重要的是，它避免了失败的代码。由客户存储它使得这更容易。