我正在考虑设置 git 服务器的分布式部署。我意识到这是 git 默认情况下所做的事情，但在这种情况下，服务器将充当单一事实来源，并提供集中支持提供的所有帮助。
目前我们的代码库和使用该服务器的开发人员数量很少(几百人)，但一旦部署，我预计至少有 1000 名用户会采用他们的自动化构建。当发生这种情况时，我预计向集中支持的 git 服务器的推送数量会增加数倍，这将导致向其他集中支持的 git 服务器推送更多内容。
为了限制由所有这些服务器相互推送更改而引起的推送 Storm 的可能性，我计划采用标准的中心辐射架构，其中一台或两台服务器将充当主服务器，接收来自辐射服务器的推送和将这些更改推回其他辐条。
当我开始考虑来自位于全局各地的分支服务器在集线器上备份的多次推送的影响时，我的问题就出现了。我试图在我的实验室中模拟这种情况，从我所看到的情况来看，推送过程只是挂起等待它前面的过程完成。在小型部署中，这工作得很好。但是，当您将构建自动化投入工作时，提交/推送事件会呈指数级增长。如果我决定创建一个接收后 Hook ，在每个客户端推送的基础上处理这些推送，我可以预见这样一种情况，即这些进程可以在客户端服务器上备份，等待集线器接收更改。
我的问题是:
我的担忧是否成立？这些进程是否会在被中心接收之前一直闲置，从而影响工作？客户端不会意识到这种状态，因为推送过程会从原始接收中 fork 出来。但是，他们会发现更改会延迟出现在其他远程服务器上。
如果这些进程会失败，它们的失败是基于 sshd 的等待间隔还是 git 本身有指定等待间隔的方法？
除了监视系统进程或包装推送命令以跟踪其完成时间之外，是否有办法检测此操作积压，或者与此相关的主服务器上的挂起接收条件？
谁能给我指点一些关于这个主题的话题或文章？
最坏的情况是，使用定时间隔的推送可以用于每个存储库，而不是基于钩子(Hook)的推送，但我希望让事情尽可能自由和快速，因此首选基于钩子(Hook)的推送。
最佳答案
您是否真的在关注如此高的推送量以至于可以对服务器进行 DoS 攻击？我不完全相信你的问题。
推送是这样工作的:
- 本地端与远程端稍微交谈，足以弄清楚它需要传输哪些对象。
- 本端将所有需要的对象打包成packfile
- 本地端将包文件传输到远程端，并以临时文件名存储在远程端
- 传输完成后，包文件将重命名为真实文件名。
- 存储库尝试按要求更新 refs(例如，将 master 分支指向新推送的提交)
传输可以并行进行。所以您真正需要担心的是您是否有足够的网络容量来维持所有推送，我怀疑这不是一个问题。推送和获取非常小。它们只传输必要的对象(另一侧已经没有的对象)，并且它们根据另一侧已有的对象对内容进行增量压缩，因此大小与 diff< 的大小成正比/em> 转移的提交代表。如果您无法处理那么多数据的传输，那么我不确定任何分布式源代码控制系统是否适合您。
也就是说，如果两个人设法同时推送到同一个分支，您仍然会遇到问题，更有可能的是，如果一个人认为他们是最新的并且可以推送，那么在他们设法推送之前，其他人推送，因此第一个开发人员必须在推送之前 pull 。这些都是非常现实的问题，但处理它们的方法不是通过分发您的存储库。这是通过采用不能完全避免这种情况的工作流程。
首先，如果您实际上正在查看一千个开发人员，他们可能并不都在同一个存储库中工作，对吧？如果他们是……你可能想把它分开。如果需要在某个高级别将事物捆绑在一起，请查看子模块。例如，这就是 Linux 内核源代码的存储方式。有很多位，每个位都在自己的子模块中，然后是父存储库的一部分。没有多少人需要弄乱父存储库；他们只是处理他们正在处理的子模块的 repo 协议(protocol)，并没有太多人在做这件事。您真的不希望处于拥有代表 1000 万行代码的单一存储库的情况。
现在，如果在拆分之后，您想进一步减少与许多人试图推送到一个分支有关的问题，您可能只想停止这种情况。让一个集成商(或几个)推送到主要分支，让其他人只推送到他们自己的分支，集成商可以 merge 。有很多变体，但您明白了。
最后，如果可以避免的话，尽量不要做 hub/spoke 的事情。大型开源项目成功地从单个存储库托管，因此它似乎也适用于您。请记住，大多数操作都是增量操作(推送/获取)，而不是全部操作(克隆)，因此它们不会传输大量数据。如果带宽是一个问题，您将再次通过适本地拆分存储库来提供帮助；这将减少要传输的数据量。
关于git - git push 如何处理积压的工作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9317890/