7

我有几个使用 Drupal 的站点，我有几个服务器，live、dev1、dev2 ......

Drupal 的代码库 repo 很大（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钩子，最终会递归？

有什么聪明的方法可以解决这个问题吗？

4

1 回答 1

4

首先，您不会以递归结束，因为当“一切都是最新的”（如另一个问题中所述）时不会执行 post-receive 钩子，这将是来自推送的结果镜像到实时服务器。

另一方面，这并不是一个可扩展的设计（每次添加新镜像时，您都需要更改实时服务器的挂钩以添加要推送的站点）。您可能会发现在您的镜像中使用“惰性”同步策略更优雅：当他们收到推送时，他们不只是推送到主服务器，而是在此之前从主服务器获取/拉取。这样你就不需要在 master 中设置 hook，同步策略将完全由镜像管理。这种策略的缺点是您最终可能希望在需要推送任何更改之前对要传播到镜像的实时服务器进行更改。因此，您必须考虑对 master 的更改是否对补偿可伸缩性的权衡至关重要。当然，一个补丁可以让这个“可扩展”

于 2012-07-24T12:06:53.187 回答