我正在考虑将运行多个网站的代码库放入版本控制中。这个代码库有几个实例在不同的虚拟服务器上运行网站。
我正在努力解决的问题是，这些或多或少相同代码的单独实例中的每一个都具有具有特定于站点的功能的子目录。但似乎版本控制系统想要控制整个目录层次结构。
例如，每个实例都有目录
/www/smarty/libs/plugins/
您可以在哪里找到适合Smarty的网站特定功能。当我们准备将其置于版本控制中时，文件夹/www将成为根。
因此，一种选择是将所有特定于站点的功能发送到所有站点。我本身并没有看到任何问题，但它似乎在某种程度上是“错误的”。会有一堆文件只属于一个部署。
另一种选择是为代码库中每个站点的特定文件建立一个单独的存储库。但是，当试图正确部署新网站时，这听起来很快就会成为一场噩梦。
最好的方法是什么？我们正在研究的版本控制系统是颠覆。
答案 0 :(得分：2)
通常，源控制系统应该用于控制源。它们不能完全控制文件层次结构，权限和其他相关内容。这些最好留给部署配置。
如何让您需要的每个项目和目录在版本控制系统中代表一次。然后，在单独的目录（可能称为/build/）中，具有各种配置布局。您可能有一个构建每个站点或maven的ant文件。或者，您可以使用Capistrano或Fabric等工具来更好地控制每个部署。
答案 1 :(得分：1)
这些工具是灵活的（通常），所以这里有一些建议：
大多数VCS允许您通过某种机制忽略文件和目录（例如Mercurial .hg忽略文件），因此您应该能够定位您想要/应该控制的内容与不应该的内容。
将文件/目录分成公共资源项目和特定于站点的项目，然后使用构建系统将它们集成以创建可部署的程序包。构建系统可以像shell脚本或更复杂的框架一样简单。如果它是一个非常简单的集成，VCS可能具有一些用于合并基础的基本功能（例如Mercurial子存储库）。
答案 2 :(得分：1)
使用subversion，你可以拥有一堆存储库：
www位于常规存储库中plugins每个都在特定于站点的存储库中然后有嵌套的工作副本：
svn co http://www_repo www
cd www/smarty/libs
svn co http://foo_plugins_repo plugins
提示：将plugins添加到svn:ignore
www/smarty/libs属性
svn propset svn:ignore "plugins" www/smarty/libs
您当然可以使用git（通过.gitignore），也可能使用其他版本控制系统，但我不知道它们。
（或者你可以跳过嵌套的工作副本部分（可能会让一些人感到不舒服）并且并排查看内容，但是使用符号链接来代替smarty/libs/plugins，而ignore仍然属于）
答案 3 :(得分：1)
您缺少“构建”步骤，该步骤将获取源代码管理中的源并为不同的站点创建部署包。只需要一个源包，不同的构建配置会创建不同的部署包。不要试图直接将deplyoment设置为源代码控制，它不是源代码！
答案 4 :(得分：0)
我认为最好的办法是在您的存储库中为每个站点（Site-01，Site-02等）创建一个顶级目录，并在这些目录中放置源树。然后你可以单独检查项目。我认为对公司所涉及的所有项目使用相同的存储库是可以接受的并且有些标准。
我的术语可能不合时宜，但基本的想法是合理的，我相信。