代码存储库最佳实践
我在一家为各种客户进行大量定制开发的公司工作。有些项目是独特的，但其中许多项目也使用我们多年来开发的一组通用代码。这种模式长期以来一直运作良好。但我们目前正在从 SVN 迁移到 Mercurial (hg)，因此我正在考虑如何最好地设置不同的存储库。
现在我们有一个用于内部工作的存储库。这些项目范围从基本实用程序（例如日志记录）到供内部使用的自定义应用程序。而且它还有大量未主动更新的旧代码，但保留下来以防某些旧的遗留客户端代码需要修改。
对于每个客户，我们都会创建一个单独的存储库，并将其所有代码放入专用存储库中。 这种结构的好处是，如果您想处理客户的代码，您只需从他们的存储库中获取所有内容，加上“核心”内部代码，您就拥有了所需的一切。一个缺点是客户端代码可能会变得陈旧，甚至与我们的核心代码的更改不同步。
但我也想听听其他人是怎么做的。拥有许多特定于客户的存储库和一个相当大的内部存储库是否有意义？一些客户的代码库巨大，而另一些客户的代码库非常小。为每个人都有一个回购有意义吗？
此外 - 我们将所有客户端工件放入每个客户端存储库中。这不仅包括源代码，还包括规格、合同、签名的 PDF、Excel、Visio、Word 和其他此类文档。这对我来说似乎很浪费，我正在考虑将工件与真实代码分开。其他人如何处理此类事情？
I work at a company that does a good deal of custom development for a wide variety of clients. Some projects are unique, but many of them also use a common set of code that we have developed over the years. This pattern has worked well for a long time. But we are currently in the process of moving from SVN to Mercurial (hg), and so I'm pondering how best to set up the different repositories.
Right now we have one repo for our internal work. These projects range from basic utilities such as logging, to custom apps for internal use. And it also has a good deal of old code that is not actively updated, but kept around in case some old legacy client code needs to be modified.
For each client we make a separate repo and put all of their code in the dedicated repo.
The nice thing about this structure is that if you want to work on a client's code, you just get everything from their repo, plus the "core" internal code, and you have everything you need. One downside is that the client code can become stale, and even out of synch with changes to our core code.
But I would like to hear what other people do as well. Does it make sense to have many client-specific repositories and one rather large internal one? Some client's code base is huge, while others' are very small. Does it make sense to have a repo for each?
Also - we put ALL client artifacts into each client repository. This includes not only source code, but also specs, contracts, signed PDFs, Excel, Visio, Word, and other such documents. This seems wasteful to me, and I'm pondering separating out the artifacts from the true code. How do others handle such things?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以执行以下操作：
这给您带来的好处是您仍然可以提取客户端存储库并获取客户端的东西和核心代码。
另外，子存储库会自动指向核心代码存储库的某个版本，如果您想要更新的版本，则必须进行显式更新。因此，如果核心代码存储库同时更新，客户端存储库中的子存储库不会自动获取这些更改（这可能会破坏您的客户端代码）。
You could do the following:
This gives you the benefit that you can still just pull the client repository and get the client's stuff and the core code.
Plus, the subrepository automatically points to a certain revision of the core code repository, and you have to do an explicit update if you want a newer version. So if the core code repository is updated in the meantime, the subrepository in the client repository does not automatically get these changes (which might break your client code).
如果您为与核心产品代码交互的客户开发了自定义代码，您可能应该在每次核心更新时对其进行审查，以确保它不会“与我们的核心代码的更改不同步”。无论您收取维护费用还是单独进行审查和维护，这都可以有利可图。更重要的是，它避免了失败的代码。由客户端存储它可以使这变得更容易。
If you have developed custom code for clients which intereacts with your core product code, you should probably review it with every core update to ensure it does not get "out of synch with changes to our core code". Whether you are charging maintenance or separately for review and maintenance, this can be profitable. More important, it avoids failing code. Storing it by client makes doing this easier.