我想给予一些论据支持提交vendor、go.mod和go.sum。
我同意公认的答案的论点，这在技术上是不必要的，并膨胀的回购。
但这里有一个支持论点的列表：

• 构建项目并不依赖于Github/Gitlab/...或Go代理服务器上的某些代码。开源项目可能会因为审查，作者激励，许可变更或其他一些我目前无法想到的原因而消失，其中did happen on npm, the JavaScript package manager, and broke many projects。不在您的repo中，不是您的代码。
• 我们可能使用了内部或第三方Go模块（私有），这些模块也可能消失或无法访问，但如果它们是在供应商中提交的，它们是我们项目的一部分。
• 私有Go模块可能不遵循语义版本控制，这意味着Go工具在动态获取它们时将依赖于最新的提交哈希。Repo历史可能会被重写（例如rebase），并且您，同事或您的CI作业可能会最终使用不同的代码来实现它们所使用的依赖关系。
• 执行编译和构建步骤的CI/CD作业不会在每次执行CI作业时浪费时间和网络下载依赖项。所有需要的依赖项都是本地的并且存在（go build -mod vendor）
• 不需要为下载私有Go模块设置CI/CD作业身份验证（更简单）。
• Go依赖几乎总是文本文件（源代码），将它们存储在repo中非常便宜。
• 提交供应商有时可能会改进代码审查过程。通常我们总是在单独的提交中提交依赖项更改，因此如果你好奇，可以很容易地查看它们。

这里有一个有趣的关于膨胀仓库的观察。如果有人进行代码审查，团队成员包含了一个300个文件的新依赖项（或更新了一个300个文件的依赖项），如果需要的话，看看里面并最终开始讨论替代品/质量可能会很有趣。这可能会导致实际上减少二进制文件的大小和整体复杂性。
如果在一个新的合并请求中只看到go.mod中的一个新行，那么我甚至不会考虑它。

• 当提交供应商是错误的？*

vendor**不应该在项目是Go库的时候被提交（假设你创建了一个新的gorilla/mux）。只适用于生成可执行二进制文件的项目。

除非你需要修改供应商的软件包，否则你不应该这样做。Go模块已经为你提供了可复制的构建，因为go.mod文件记录了依赖项的确切版本和提交哈希，go工具将尊重并遵循这些版本和提交哈希。
vendor目录可以通过运行go mod vendor命令重新创建，默认情况下go build甚至会忽略它，除非您要求它使用-mod=vendor标志。
阅读更多详情：
Go wiki：如何在模块中使用排序？排序会消失吗？
命令go：模块和封装
命令go：制作依赖项的供应副本