我正在研究设置git服务器的分布式部署。我意识到这是git默认做的事情，但在这种情况下，所述服务器将作为单一的事实来源，并提供集中支持提供的所有帮助。
目前我们的代码库和使用服务器的开发人员数量很少（几百个），但一旦部署，我希望至少有一千个用户可以采用自动构建。当发生这种情况时，我预计对集中支持的git服务器的推送次数将会多次增加，这将导致向其他集中支持的git服务器添加推送。
为了限制所有这些服务器互相推送引起推送风暴的可能性，我计划采用标准的集线器分支架构，其中一台或两台服务器将充当主服务器，接收来自分支服务器的推送和将这些变化推回到其他辐条。
当我开始考虑备份在集线器上的全球定位的分支服务器的多次推送的影响时，我的问题出现了。我试图在我的实验室中模拟这种情况，并且从我看到的推送过程只是等待它前面的过程完成。在一个小型部署中，这很好用。但是，当您将构建自动化投入工作时，提交/推送活动可能会呈指数级增长。如果我决定在每个客户端推送的基础上创建一个处理这些推送的后接收挂钩，我可以预见这些进程可以在客户端服务器上备份，等待集线器接收更改。
我的问题是：
我的担忧有效吗？这些过程是否会通过挂出来解决工作直到它们被集线器接收？客户端将不会意识到这种状态，因为推送过程将从原始接收中分离出来。但是，他们会发现更改会在其他远程服务器上出现延迟。
如果这些进程失败，它们是否会根据sshd的等待时间间隔失败，或者git本身是否有指定等待间隔的方法？
除了监视系统进程或包装push命令以跟踪其完成时间之外，有没有办法检测此操作积压，或者主服务器上是否有挂起的接收条件？
你们有没有人能指出我处理这个问题的一些主题或文章？
最糟糕的情况是，使用定时间隔的推送可以用于每个存储库而不是基于钩子的推送，但我希望尽可能保持自由流动和快速，因此首选基于钩子的推送。
答案 0 :(得分：2)
你真的在看推送音量这么高，它可以服务器吗？我对你的问题并不完全相信。
推动这样的工作：
转移可以并行发生。所以你真正需要担心的是你是否有足够的网络容量来维持所有的推动，我怀疑这是一个问题。推送和取出非常小。它们只传输必要的对象（没有任何已经在另一侧的对象），并且它们根据另一方已经拥有的对象对内容进行增量压缩，因此大小与 diff <的大小成比例/ em>转移的提交代表。如果您无法处理传输那么多数据，那么我不确定任何分布式源代码控制系统是否可以为您工作。
也就是说，如果两个人同时设法推送到同一个分支机构，如果一个人认为他们是最新的并且可以推送，那么在他们设法推送之前，你仍然会遇到问题，其他人推，所以第一个开发商必须在推之前拉。这些都是非常实际的问题，但通过分发您的存储库，处理它们的方法是不。这是通过采用不完全避免这种情况的工作流程。
首先，如果你真的在看一千个开发人员，他们可能并非都在同一个存储库中工作，对吧？如果他们是......你可能想把它分开。如果事情需要在某个高级别联系在一起，请查看子模块。例如，这就是存储Linux内核源的方式。有很多位，每个位都在自己的子模块中，然后是父存储库的一部分。没有多少人需要弄乱父存储库;他们只是处理他们正在处理的子模块的回购，并没有太多人在研究它。您确实不希望处于拥有代表10M行代码的单一存储库的情况。
现在，如果在拆分之后，你想进一步减少许多人试图推送到一个分支的问题，你可能只想停下来。让一个集成商（或几个）推送到主分支，让其他人只需推送到他们自己的分支，集成商可以合并。有很多很多变化，但你明白了。
最后，如果你可以避免它，尽量不要做中心/说话的事情。大型开源项目是从单个存储库成功托管的，因此它似乎也适合您。请记住，大多数操作是增量（推/取），而不是总（克隆），因此它们不会传输大量数据。如果需要考虑带宽，则可以通过正确拆分存储库来帮助您;这将减少要传输的数据量。