我在go1.12上使用go模块来处理我的Go依赖项。最好也将vendor/
目录提交到版本控制中吗?
这与Is it best-practice to commit the vendor
directory?有些关系,它在使用dep
的情况下提出了这个问题。对于dep
,提交vendor/
是获得真正可重现构建的唯一方法。对于go模块呢?
我在go1.12上使用go模块来处理我的Go依赖项。最好也将vendor/
目录提交到版本控制中吗?
这与Is it best-practice to commit the vendor
directory?有些关系,它在使用dep
的情况下提出了这个问题。对于dep
,提交vendor/
是获得真正可重现构建的唯一方法。对于go模块呢?
2条答案
按热度按时间ruoxqz4g1#
我想给予一些论据支持提交
vendor
、go.mod
和go.sum
。我同意公认的答案的论点,这在技术上是不必要的,并膨胀的回购。
但这里有一个支持论点的列表:
go build -mod vendor
)这里有一个有趣的关于膨胀仓库的观察。如果有人进行代码审查,团队成员包含了一个300个文件的新依赖项(或更新了一个300个文件的依赖项),如果需要的话,看看里面并最终开始讨论替代品/质量可能会很有趣。这可能会导致实际上减少二进制文件的大小和整体复杂性。
如果在一个新的合并请求中只看到
go.mod
中的一个新行,那么我甚至不会考虑它。vendor
**不应该在项目是Go库的时候被提交(假设你创建了一个新的gorilla/mux)。只适用于生成可执行二进制文件的项目。8yoxcaq72#
除非你需要修改供应商的软件包,否则你不应该这样做。Go模块已经为你提供了可复制的构建,因为
go.mod
文件记录了依赖项的确切版本和提交哈希,go
工具将尊重并遵循这些版本和提交哈希。vendor
目录可以通过运行go mod vendor
命令重新创建,默认情况下go build
甚至会忽略它,除非您要求它使用-mod=vendor
标志。阅读更多详情:
Go wiki:如何在模块中使用排序?排序会消失吗?
命令go:模块和封装
命令go:制作依赖项的供应副本