version-control - 在处理许多具有通用代码库的小项目时，良好的 github 结构？

Question

我在一家网络开发公司工作，我们正在考虑使用 GitHub 进行版本控制。我们与几个不同的基于 .NET 的 CMS 平台合作，当然还有很多不同的客户。

我们为每个 CMS 都有一个标准代码库，我们在构建新站点时会从这些代码库开始。我们当然希望保持这一点，并使合并来自已开发站点的一些更改成为可能(当标准代码库以某种方式得到改进时)。

我们经常需要在以后对已发布的站点进行小的更改，并且希望能够以最小的努力完成此操作(即客户很乐意为我们在 2 小时内解决他的问题付费，但不想先支付 2 小时的设置费用)。

我们应该如何设置它才能以高效的方式工作？我不太习惯分布式版本控制(我以前使用过 CVS、Subversion 和 Clear Case)，但根据我的想象我们可以:

1. 为每个客户设置一个存储库，从标准代码库的副本开始，然后从那里开始。当然有很多存储库。
2. 为每个 CMS 设置一个存储库，然后为每个客户分出一个分支。这可能是(？)最好的方法，但是当我们在同一个存储库中有 100 个客户(=分支机构)时会发生什么？我们创建了很多分支，我们真的没有任何打算合并回主分支，这也让人感觉不太好。

我不知道，也许很多分支只是我想象中的问题，或者也许有我没有想过的更好的方法来做到这一点。我会对类似问题的任何经验感兴趣。

感谢您的宝贵时间和帮助。

Answer 1

使用 Git，多个存储库对于子模块的目的是有意义的(共享公共(public)组件，请参阅答案的第三部分中的 nature of Git submodules)

但在您的情况下，只要您使用分支机构来:

• 隔离一些特定于客户端的更改(并且没有合并回 master 的长期分支是可以的)，
• 同时将这些相同的分支重新设置在 master 之上(其中包含通用代码，以及所有分支所需的共同演进)。