Git - 为大型项目推送远程分支真的很慢

Question

我们只是在我的工作中使用 git。我们有一个相当大的项目，其中有一些相当大的资源处于版本控制之下 (~500MB)。

今天我们尝试将分支推送到远程服务器，但很惊讶 git 似乎正在尝试上传整个项目。我本来希望 git 只发送 4-5 个发生更改的文本文件的增量（就像正常推送到 master 一样）。这不是远程分支的工作方式吗？我们使用了git push origin some_branch_name，在这种情况下有没有更好的命令可以使用？我们不应该在 git 中存储大量资源吗？如果不是，人们通常如何处理这种情况？有没有更好的方法让一名开发人员与另一名开发人员共享正在进行的工作而无需将更改提交到主分支？就目前而言，我们正在考虑大约 15 分钟来推送一个远程分支，这真的不可行。我们做错了什么？

Answer 1

你能更新你的帖子吗？

为了更好地了解您的项目的外观，请发布以下前 10 多个条目：

git log --decorate=short --oneline --graph --all

如果大型资源是二进制文件，那么不应该将它们存储在 git 中。如果这些二进制资源被更新，那么 git 那么它必须在内部对它们进行完整的复制，这是压缩算法不喜欢的，并将它们发送到服务器。至于如何处理它们，这取决于场景。您需要详细说明。

听起来您有多个开发人员在同一个遥控器上工作。它是否正确？如果是这样，任何开发人员都不应该直接提交给master（恕我直言，无论如何都不应该发生）。每个开发人员都可以拥有自己的命名分支。例如，开发人员 John 可以在 john/<branch_name> 下创建他的所有分支。这将有助于保持工作流程整洁。

此外，git 不适用于增量。每次更改时，它都会完整地存储文件。这可能看起来效率低下，但使用的压缩将大小保持在最低限度。它有助于更​​快地结帐和扫描日志历史记录。阅读Git Basics 的第一部分以获得可视化效果。

Answer 2

另一个因素可以解释git push性能不佳：

“git push”用于在处理 refs 的旧值和新值列表时检查对象名称和 refnames 之间的歧义，这是不必要的（因为它知道它正在提供原始对象名称）。

见commit a4544b3（2018 年 11 月 6 日）Derrick Stolee (derrickstolee)。
帮助者：Jeff King (peff)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 1373999，2018 年 11 月 19 日）}

pack-objects：忽略不明确的对象警告

git push 进程在其运行期间运行多个进程，但其中一个包括 git send-pack，它调用 git pack-objects 并使用对象 ID 将已知的拥有/想要传递到标准输入。

但是，core.warnAmbiguousRefs 的默认设置需要 git pack-objects 检查与refs.c 中的ref_rev_parse_rules 数组匹配的引用名称。
这意味着每个对象都至少触发了六个“文件是否存在？”查询。

当有很多参考时，这可能会显着增加！
我观察到一个简单的推送花了三秒钟检查这些路径。

Git 2.20（2018 年第四季度）已修复此问题。