代码库最佳实践 [英] Code Repository best practices

问题描述

我在一家为众多客户进行大量定制开发的公司工作.有些项目是独特的，但其中许多项目也使用了我们多年来开发的一组通用代码.这种模式已经运行了很长时间了.但是我们目前正在从SVN迁移到Mercurial(hg)，因此我正在考虑如何最好地建立不同的存储库.

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?

此外-我们将所有客户端工件放入每个客户端存储库中.这不仅包括源代码，还包括规范，合同，已签名的PDF，Excel，Visio，Word和其他此类文档.这对我来说似乎很浪费，我正在考虑将工件与真正的代码分开.别人如何处理这类事情?

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?

推荐答案

您可以执行以下操作:

• 将核心代码放在一个中央存储库中
• 将客户端代码放入特定于客户的存储库中
• 不要不直接将核心代码副本放置在客户端存储库中，而是将核心代码存储库作为

• put the core code in one central repository
• put the client code in client-specific repositories
• do not put copies of the core code directly in the client repositories, instead include the core code repository as a subrepository

这给您带来的好处是，您仍然可以仅提取客户端存储库并获得和客户端代码.
另外，子存储库会自动指向核心代码存储库的特定修订版，如果要更新的版本，则必须进行显式更新.因此，如果同时更新核心代码存储库，则客户端存储库中的子存储库不会不自动获得这些更改(这可能会破坏您的客户端代码).

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).

这篇关于代码库最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！