git push如何处理积压工作

我正在考虑建立git服务器的分布式部署。我意识到这是git默认做的事情，但在本例中，服务器将在集中支持提供的所有帮助下充当唯一的真相来源

目前，我们的代码库和使用服务器的开发人员数量很少（几百人），但一旦部署，我预计至少会有1000名用户与他们的自动构建一起采用。当这种情况发生时，我预计对中央支持的git服务器的推送数量将增加数倍，这将导致对其他中央支持的git服务器的推送增加

为了限制所有这些服务器相互推送更改而导致推送风暴的可能性，我计划采用标准的中心辐射式体系结构，其中一个或两个服务器将充当主服务器，从辐射式服务器接收推送，并将这些更改推送回其他辐射式服务器

当我开始考虑来自全球定位的轮辐服务器上的多个推送对集线器的影响时，我的问题就出现了。我曾试图在我的实验室中模拟这种情况，从我所看到的情况来看，推送过程只是挂起等待前面的过程完成。在一个小的部署中，这工作得很好。然而，当您将构建自动化引入works时，提交/推送活动可能会成倍增加。如果我决定创建一个post-receive钩子，在每个客户端推送的基础上处理这些推送，那么我可以预见这样一种情况，即这些进程可以备份到客户端服务器上，等待中心接收更改

我的问题是：

我的担心有效吗？这些流程是否会在枢纽接收之前一直挂在外面，从而使工程变得一团糟？客户机将不知道这种状态，因为推送过程将从原始接收分叉。但是，他们会发现，在其他远程服务器上出现的更改会延迟

如果这些进程将失败，它们是基于sshd的等待间隔失败的，还是git本身有指定等待间隔的方法

除了监视系统进程或包装push命令以跟踪其完成时间外，是否有方法检测此操作积压，或者主服务器上的挂起接收情况

你能告诉我一些关于这个主题的线索或文章吗

---

最糟糕的情况是，每个存储库都可以使用一个使用定时间隔的推送来代替基于钩子的推送，但我希望尽可能让事情保持自由和快速，以便首选基于钩子的推送。

您是否真的认为推送量如此之大，以至于服务器无法运行？你的问题并不能完全说服我

我们的工作是这样的：

• 本地端与远程端进行一点对话，足以确定需要传输哪些对象
• 本地端将所有必需的对象打包到一个打包文件中
• 本地端将packfile传输到远程端，并将其存储在临时文件名下
• 传输完成后，packfile将重命名为实际文件名
• 存储库尝试根据请求更新引用（例如，将主分支指向新推送的提交）

传输可以并行进行。所以你真正需要担心的是你是否有足够的网络容量来支持所有的推送，我怀疑这是个问题。推送和获取非常小。它们只传输必要的对象（另一端没有任何对象），并基于另一端已有的对象对内容进行增量压缩，因此大小与传输的提交所代表的差异大小成比例。如果您不能处理传输那么多数据，那么我不确定任何分布式源代码管理系统是否能为您工作

也就是说，如果两个人同时设法推送到同一个分支，你仍然会遇到问题。更可能的是，如果一个人认为他们是最新的，并且可以推送，那么在他们设法推送之前，其他人推送，所以第一个开发人员必须在推送之前先推送。这些都是非常真实的问题，但解决这些问题的方法是而不是通过分发存储库。这是通过采用一个不会完全避免这种情况的工作流实现的

首先，如果你真的关注一千名开发人员，他们可能不是都在同一个存储库中工作，对吗？如果他们是。。。你可能想把它分开。如果需要在某个较高的层次上结合起来，请查看子模块。例如，Linux内核源代码就是这样存储的。有很多位，每个位都在它们自己的子模块中，它们是父存储库的一部分。没有多少人需要处理父存储库；他们只是处理他们正在处理的子模块的回购协议，没有太多人在处理。您真的不希望出现一个代表10万行代码的单片存储库的情况

现在，如果在分裂之后，你想进一步减少很多人试图推动一个分支的问题，你可能想停止这一点。让一个集成器（或几个集成器）推送到主分支，让其他人推送到自己的分支，集成器可以合并这些分支。这方面有很多变化，但你明白了

最后，如果你能避免它，尽量不要做中心/辐射的事情。大型开源项目成功地从单个存储库托管，因此它似乎也适用于您。请记住，大多数操作都是增量操作（推送/获取），而不是总操作（克隆），因此它们不会传输大量数据。如果带宽是一个问题，您将再次通过拆分得到帮助