我有几个使用 Drupal 的网站，我有几个服务器，live、dev1、dev2...
Drupal 的代码库存储库很大（112Mb），所以我热衷于充分利用 git 的硬链接功能，这样每次我添加一个站点时都不会重复它。
因此，比如说，我的实时服务器有一个裸露的主存储库，而我的所有站点都是它的克隆，每个站点都使用不同的分支。这在一台服务器上非常棒，使用硬链接，快速高效。
但在我的开发服务器上，它们通常都是从裸主存储库克隆的，这意味着同一台计算机上的两个站点不能使用硬链接来节省空间。
我想做的是在我的每台开发服务器上设置裸存储库的镜像，然后从中进行克隆。
dev1$ git clone --mirror live:master-bare-repo dev1-mirror-repo
dev1$ git clone -b site1 dev1-mirror-repo site1
dev1$ git clone -b site2 dev1-mirror-repo site2
到目前为止一切都很好。但我希望镜子始终保持同步。所以我用了接收后挂钩 http://git-scm.com/book/en/Customizing-Git-Git-Hooks在 dev1 的镜像上要做的事git push --mirror origin。现在，如果 dev1 上的 site1 推送提交，它们会神奇地推送到 master-bare-repo。
But如果我做出改变怎么办live服务器，并推送那个？我无法设置post-receive钩子推送到其他人，因为这可能会触发their post-receive哪些钩子最终会递归？
有什么聪明的方法可以解决这个问题吗？
首先，你不会以递归结束，因为当“一切都是最新的”时，接收后挂钩不会执行（如这另一个问题 https://stackoverflow.com/questions/10878495/git-post-receive-hook-for-everything-up-to-date），这将是以下结果pushes从镜像到实时服务器。
另一方面，这并不是可扩展设计的全部（每次添加新镜像时，您都需要更改实时服务器的挂钩以添加要推送的站点）。您可能会发现在镜像中使用“惰性”同步策略更加优雅：当它们收到推送时，它们不仅推送到主服务器，而且在此之前它们从主服务器获取/拉取。这样你就不需要在主服务器中设置钩子，同步策略将完全由镜像管理。此策略的缺点是，您最终可能希望对实时服务器进行更改，并在镜像需要推送任何更改之前将其传播到镜像。因此，您必须考虑对主控的更改对于补偿可扩展性的权衡是否如此重要。当然，使这种“可扩展”设计也“可同步”的补丁是使用外部 cron 作业定期检查 master 中的更改，如评论中所建议的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
