git push如何处理积压

Question

我正在研究设置git服务器的分布式部署。我意识到这是默认情况下git所做的事情，但在这种情况下，所有服务器都将作为单一的事实来源，并提供集中支持提供的所有帮助。

目前我们的代码库和使用服务器的开发人员数量小（几百个），但一旦部署我期待与他们的自动化生成至少一个数千用户采用沿。当发生这种情况时，我预计将推动中央支持的git服务器数量增加多倍，这将导致增加推送到其他集中支持的git服务器。

为了限制由所有这些服务器引起的推送风暴的可能性，我打算采用标准的集线器辐条架构，其中一个或两个服务器充当主服务器，接收来自辐射服务器的推送并将这些变化推回到其他辐条。当我开始考虑从全球范围讲位于服务器上的枢纽备份多个推的影响

我的问题就出现了。我试图在我的实验室中模拟这种情况，并且从我所看到的推送过程只是等待其前面的过程完成。在小型部署中，这很好。但是，当您将构建自动化投入到工作中时，提交/推送活动可以呈指数级增长。如果我决定创建一个post-receive钩子来处理这些按客户端推送的推送，我可以预见这些进程可以在等待中心接收更改的客户端服务器上备份的情况。

我的问题是：

我的顾虑是否有效？这些过程是否会将这些作品挂在外面，直到它们被中心收到为止？客户将不知道这种状态，因为推送过程将被分离出原始接收。但是，他们会发现其他远程服务器上的更改会延迟。

如果这些进程会失败，难道他们失败是对的sshd的等待时间或根本的git本身具有指定等待区间的方法？

除了监视系统进程或包装的推出指令跟踪其完成时间，有没有一种方法来检测这种操作积压，或为此事挂得到在主服务器上的条件？

你任何人都可以点我对处理这个问题的一些主题或文章？

最糟糕的情况是，使用定时间隔的推送可以用于每个存储库，而不是基于挂钩的推送，但我希望尽可能保持自由流畅，因此基于挂钩的推送将是首选。

Answer 1

你真正看到一个推量如此之高，它可以在DOS的服务器？我不完全相信你的问题。

推动这样的工作：

• 局端会谈到远程的一面位，足以弄清楚它需要转什么对象。
• 当地侧包了所有必需的对象为打包文件
• 本地端的打包文件传输到远端，在那里的一个临时文件名
• 的打包文件重命名为一个真正的文件名存储传送完毕。
• 储存库试图按要求更新参（例如主分支指向新推提交它）

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

也就是说，如果两个人同时推送到同一个分支，那么您仍然可能遇到问题，更有可能的是，如果一个人认为他们是最新的并且可以推送，那么在他们设法推，别人推，所以第一个开发者必须在推之前拉。这些都是非常现实的问题，但通过发布您的存储库，处理这些问题的方式是而不是。这是通过采用不会完全避免这种情况的工作流程。首先，如果你真的在寻找一千个开发人员，他们可能并不都在同一个仓库中工作，对不对？如果他们......你可能想分解它。如果需要将某些事情绑定在一起，请查看子模块。例如，这是如何存储Linux内核源码的。有很多位，每个位于它们自己的子模块中，然后它们是父存储库的一部分。没有多少人需要捣乱父库;他们只是处理他们正在从事的子模块的回购，并没有太多人在为此工作。你真的不想成为拥有代表10M行代码的单一存储库的情况。

现在，如果在分裂之后，你想进一步减少许多试图推向一个分支的人的问题，那么你可能想要停下来。让一个集成商（或几个）推到主要分支，并让其他人只是推到他们自己的分支，集成者可以合并。这方面有很多很多变化，但你明白了。

最后，如果你可以避免它，尽量不要做hub/spoke事情。大型开源项目已成功从单个存储库托管，因此它似乎也可能适用于您。请记住，大多数操作是增量式（推/取），而不是全部（克隆），因此它们不会传输大量数据。如果需要考虑带宽问题，您将再次得到正确分解存储库的帮助;这将减少要传输的数据量。