如果第二次推送只有第一次推送的快进,那么并发git推送是否总是安全的？

Question

我想自动将后接收挂钩中的提交从我们LAN上的中央仓库推送到云中的另一个中央仓库.LAN repo使用git clone --mirror git@cloud:/path/to/repo或等效命令创建.

因为提交的文件相对于我们的上游带宽会很大,所以完全有可能发生这样的事情:

1. Alice启动了对LAN repo的推送.
2. 在收件后挂钩运行时,Bill从LAN repo中拉出来.
   • 局域网回购正在推动云回购.
   • 这也意味着Bill的本地仓库包含Alice推送的提交.通过测试确认.
3. 比尔开始推动局域网回购.
   • 比尔的推动是爱丽丝推进的快速前进,因此局域网回购将接受它.

当LAN repo的后接收挂钩执行时,将从LAN repo到cloud repo的第二次推送开始,并且两者将同时运行.

我并不担心git对象.最糟糕的情况是两个推送都会从Alice的推送中上传所有对象,但就我理解git的内部结构而言,这应该无关紧要.

我很担心裁判.假设Alice推动使用更慢的连接,因此Bill的推送首先完成.假设数据包丢失或其他原因导致挂钩从局域网仓库推送到Bill的推送云完成,然后钩子从局域网回购推送到Alice的推送云.如果Alice和Bill都在推动主分支并且Bill的推送首先完成,那么主要参与者将在云回购中做什么？我希望它成为比尔的头,因为那是后来的推动,但我担心这将是爱丽丝的头.

进一步澄清:

我意识到,如果比尔从他的机器推送到局域网回购完成,那么爱丽丝从她的机器到局域网回购的推动将会失败.在这种情况下,LAN repo的post-receive挂钩将不会执行.此外,请假设没有人会进行强制推送,因此如果后续接收挂钩在LAN repo上运行,则所有参考更改都是快进的.

Answer 1

如果 Bill 的推送先完成，Alice 的推送将会失败，因为在更新引用之前，git 确保存储库的引用仍然与之前相同。在这种情况下，情况不会如此。Alice 最终会看到错误消息并需要解决问题。反之亦然，比尔也是如此。因此，在您的 post-receive 挂钩中，您必须确保存储库的原始引用和新引用现在不同。如果没有，那么根本不要推送到新的存储库以节省一些工作。

不过，我仍然在您的场景中发现了一个问题，它与推送到云有关。将两个有效引用推送到云位置的挂钩可能会遇到同样的问题。除了现在，如果第一次失败，您将不知道是否需要推送到脚本中的存储库，因为您不知道失败的引用是否比推送的引用更旧或更新......特别是如果它们不简单快进有时会发生。如果你只是强制推送，无论发生什么，云都有可能有一个 OLD ref，直到另一个钩子稍后推送其他内容。在爱丽丝的情况下，他会合并来自上游或任何其他解决方案的更改，但脚本可能不应该具有这样的决策能力。

在钩子中，您可能可以对当前存储库执行一些脚本魔法来确定时间戳等，并且仅在存在快进时才推送，但这看起来很混乱，而且更有可能需要合并。我认为比使用 post-receive hook 更好的解决方案是每五分钟（或您想要的频率）使用一个 cron 或计划任务，该任务只需在远程镜像的 master 分支上运行 git pull 即可。如果您无权访问该存储库，则可以使用 cron 作业从 LAN 存储库强制推送。我认为这比钩子更安全，也更简单。这将确保您每隔几分钟备份云上的分支总是位于正确的位置，并且不会冒险推送较旧的引用，并且在用户再次推送之前永远不会获取最新的引用，就像钩子一样。