始终保持git镜像同步 [英] Keeping git mirrors in sync at all times
问题描述
Drupal的代码库回购很大（112Mb），所以我我非常希望充分利用git的硬连接能力，这样每次我添加一个网站时，都不会重复这一点。
所以，比方说，在线服务器I有一个裸主回购，我的所有网站都是这个克隆，每个使用不同的分支。这在一台服务器上很棒，使用硬链接，速度快，效率高。但是在我的开发服务器上，它们通常都是裸机主存储库的副本，意味着同一台机器上的两个站点不能使用硬链接来节省空间。
我想要做的是在每个设备上设置裸露回购的镜像我的开发服务器，然后克隆。
dev1 $ git clone --mirror live：master-bare-repo dev1 -mirror-repo
dev1 $ git clone -b site1 dev1-mirror-repo site1 $ b $ dev1 $ git clone -b site2 dev1-mirror-repo site2
到目前为止都是很好的。但我希望镜子始终保持同步。所以我在dev1的镜像上使用了 post-receive hook 来完成 git push --mirror origin 。现在，如果dev1上的site1推送提交，它们会被神奇地推送到master-bare-repo。
但是如果我做了更改 live 服务器，并推送？我无法设置 post-receive 挂钩推送到其他（s），因为这可能会触发 post-receive 钩子会以递归结束？
有没有一些巧妙的解决方法？
首先，你不会以递归结束，因为post-receive钩子不会在一切都是最新的（如这个问题），这将是从镜像到活动服务器的推送的结果。
另一方面，这不是全部的可扩展设计（每次添加新镜像时，都需要更改实时服务器的挂钩以添加要推送的站点）。您可能会发现，在镜像中使用懒惰同步策略会更优雅：当他们收到推送请求时，他们不会推送给主服务器，但在此之前他们会从主服务器中取/拉。这样您就不需要在主设备中设置挂钩，并且同步策略将完全由镜像管理。这个策略的缺点是，你可能最终想要改变你想传播到镜像的活动服务器，然后他们需要推动任何改变。因此，您必须思考对您的主人进行的更改对于弥补可扩展性的权衡是如此重要。当然，使这个可伸缩设计也是可同步的补丁是通过使用外部cron作业来定期检查master中的变化，如评论中所建议的。
I have several sites that use Drupal, I have several servers, live, dev1, dev2...
Drupal's codebase repo is big (112Mb), so I'm keen to make the most of git's hard-linking abilities so that each time I add a site it's not duplicating this.
So on, say, the live server I have a bare master repo, and all my sites are clones of this, each using a different branch. This is great on the one server, hard links are used, it's fast and efficient.
But on my dev servers, they typically all clone from the bare master repo, which means two sites on the same machine can't use hard links to save space.
What I'd like to do is set up a mirror of the bare repo on each of my dev servers, and then clone from that.
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
All good so far. But I want the mirrors to stay in sync at all times. So I used post-receive hook on dev1's mirror to do git push --mirror origin. Now if site1 on dev1 pushes commits, they are magically pushed to the master-bare-repo.
But what if I make a change on the live server, and push that? I can't set up a post-receive hook to push to the other(s) because that would presumably trigger their post-receive hooks which would end up in recursion?
Is there some clever way around this?
First of all, you won't end up in a recursion, since the post-receive hook isn't executed when "Everything is up to date" (as noted in this other question), which will be the result of the pushes from the mirrors to the live server.
On the other hand, that's not all of a scalable design (every time you add a new mirror, you'll need to change your live server's hook to add a site to push). You'll probably find more elegant to use a "lazy" sync strategy in your mirrors: when they receive a push they don't just push to the master, but before that they fetch/pull from the master. This way you don't need to setup a hook in the master and synchronization strategy will be completely managed by mirrors. The downside of this strategy is that you might eventually want to make a change to the live server that you want to be propagated to the mirrors before they need to push any change. So you have to ponder whether changes to your masters will be so critical to compensate the trade-off in scalability. Of course, a patch to make this "scalable" design also "synchronizable" is by using an external cron job to check periodically for changes in master, as suggested in comments.
这篇关于始终保持git镜像同步的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
