我应该提交 Godeps/_workspace 还是 Godeps.json 就足够了？

Question

我正在用 Go 编写一个项目以部署在 heroku 上，使用godep管理依赖项。

当 I 时godep save，我得到了一个Godeps.json列出我的依赖项和版本的文件和一个_workspace/复制了所有依赖项源的目录。我宁愿不提交_workspace，所有这些代码都已经在其他地方的 github 上。它似乎Godeps.json具有我们go get在 heroku buildpack 时版本锁定依赖项所需的所有信息。

有几个 来源建议提交完整Godeps/目录，但其他来源建议可能没有必要。

Godep 文档没有太大帮助：

这会将依赖项列表保存到文件 Godeps/Godeps.json，并将它们的源代码复制到 Godeps/_workspace。通读它的内容并确保它看起来合理。然后将文件提交到版本控制。

Godeps.json是文件吗？

Answer 1

官方回复：来自 GitHub 问题#131：的预期用途godep是供应商依赖项并将 _workspace 目录提交给版本控制。请参阅#123 中链接的@kr 的提案文档（提案：http : //goo.gl/RpYs8e） 正如该提案中所讨论的，godep 曾经有一种模式 (-copy=false) 支持不提供依赖项。我的猜测是自述文件中的歧义语言可能是由于这个原因。如#123 中所述，此模式已被删除。这里也是godep作者谈论他的项目和背后的想法 - Vendoring and Import Path Rewriting个人意见：我认为没有正确的方法来做到这一点。提交供应商库确实看起来很尴尬，但它有它的优点：您不依赖外部服务（GitHub 等）。GitHub 出现中断，也许你有一些可怕的公司政策阻止你使用它，也许存储库消失了或者它的历史被重写了，也许你在防火墙后面（临时/构建服务器），等等。每次对您的 deps 进行更新时，您都会对发生的变化有一个很好的差异。这有助于更新到较新版本，或者如果您筛选正在使用的代码，则仅跟踪更改。最后由你来权衡利弊。我个人每次必须提交供应商代码时都会畏缩，但在我的 Go 项目中我会这样做。至少目前是这样。此外，像 Google 和 Facebook 这样的公司大多将所有内容都保存在一个存储库中，其中包括供应商代码（或者我听说过）。

Answer 2

Godep 将需要 json 文件来读回依赖项，如update.go.因此该文件需要进行版本控制。但是，godep 会填充 的内容godep/_workspace，这意味着它是“生成”的内容：您不需要对其进行版本控制。

Answer 3

只需将 Godeps.json 文件添加到 repo，并将 _workspace 添加到 .gitignore 列表:)。虽然您的代码应该完全包含在您的存储库中，但必须以某种方式引用依赖项（godep.json、package.json、git submodule...您选择），仅此而已。同样的策略适用于 npm、bower、apt 和所有其他包管理器。你的仓库 - 你的东西 + 对供应商库的引用（当然，如果可能，你不能引用 sourceforge zip 文件）。