我有几个使用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
到目前为止一切顺利。但我希望镜子始终保持同步。所以我在dev1的镜像上用post-receive hook做git push --mirror origin。现在，如果dev1上的site1推送提交，它们会被神奇地推送到master-bare-repo。
但是如果我在实时服务器上进行更改并推送该怎么办？我无法设置一个post-receive钩子来推送到其他人，因为这可能会触发他们的 post-receive钩子，最终会递归递归？
这有什么聪明的方法吗？
答案 0 :(得分：4)
首先，你不会以递归结束，因为当“一切都是最新的”时，不会执行post-receive挂钩（如{{3}中所述） }），这将是从镜像推送到实时服务器的结果。
另一方面，这不是一个可扩展的设计（每次添加新镜像时，您都需要更改实时服务器的挂钩以添加要推送的站点）。您可能会发现在镜像中使用“延迟”同步策略会更优雅：当他们收到推送时，他们不仅仅是推送到主服务器，而是在此之前他们从主服务器获取/提取。这样您就不需要在主服务器中设置挂钩，同步策略将完全由镜像管理。此策略的缺点是，您可能最终希望在需要推送任何更改之前对要传播到镜像的实时服务器进行更改。所以你必须思考，对你的主人的改变是否对于弥补可扩展性的折衷至关重要。当然，使这种“可扩展”设计“同步”的补丁是通过使用外部cron作业定期检查master中的更改，如评论中所示。