我有几个（＆gt; 10）git存储库需要在不同的计算机上拥有多个裸存储库。所有副本需要始终保持彼此同步，并且访问它们的所有计算机上的管理开销最小。
我正在探索的当前解决方案是设置多个这样的起源：
git remote add origin ssh://host1.domain1.com/home/git/project.git
git remote set-url --add origin ssh://host2.domain2.com/z/project.git
最初，这很有效。每次推送更改（git push -u origin master）时，所有repo副本都会更新，并且所有内容始终保持同步。
但是，当我去另一台机器并克隆存储库时，我感到非常震惊。当我去推动改变时，它只去了我克隆过的回购。如果我没有注意到这一点并立即解决了这个问题，那么一个严重的问题就会随着另一个代理商的悄悄过时的代码而产生。我想你可能不想在.git/config文件中硬编码起源，这是可以理解的，但令人讨厌的是，似乎没有任何方法可以解决这个问题。如果你真的想要这样做。但是，必须有一些最佳实践才能实现总体目标，对吗？
现在我想，每个客户都可以克隆一个回购，以要求额外的＆＃34; git remote set-url -add...＆＃34;命令运行。但这假设了很多。执行拉动的人必须知道他们克隆的特定仓库的起源（它们都不相同）。他们必须记住至少运行一个额外的命令来添加额外的原点。他们必须正确地制定命令（例如，如果他们从host1拉出他们必须添加host2，但如果他们从host2拉出他们必须改为添加host1）。并且他们必须成功地为他们在每台机器上执行的每个克隆完成所有这些操作。这将成为一场行政噩梦。
我已经寻找了各种解决方案，有些建议在克隆之后运行某种脚本。这似乎并不特别是跨平台（现在必须开发一个脚本才能在所使用的每个平台上运行），也不是万无一失（如何确保它始终运行？如何直观地添加哪些来源？ ？）
同样，我希望避免在服务器上运行挂钩，因为没有脚本会在没有大量开发时间的情况下在每台服务器上运行跨平台。
我一直在想我必须错过一些简单的方法来完成这个并不需要脚本。
答案 0 :(得分：1)
是的，git遥控器会修改repo的本地配置，顾名思义，该配置是 local （for security reason）。 在另一台机器上克隆该repo时，同样的配置也不存在。
更有意思的是选择其中一个远程回购作为看门人，每个人都克隆并推送到。 那个远程仓库可以有post-receive hook负责推送到其他机器的裸仓。
或者：每个开发人员克隆来自特定的远程裸仓库，并且每个远程裸仓库都有一个后接收挂钩推送到所有其他裸仓库（但冲突的风险更高）。
简而言之：执行策略最好在远程端完成，而不是在本地完成。