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

Question

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

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

Severalsources 建议提交完整的Godeps/ 目录，但其他人建议提交might not be necessary。

godep 文档没有多大帮助：

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

是 Godeps.json 文件吗？

Answer 1

godep 需要 json 文件才能读回依赖项，如 update.go 所示。
所以该文件需要进行版本控制。

然后godep would fill the content of godep/_workspace，这意味着它是一个“生成”的内容：你不需要版本它。

Answer 2

只需将 Godeps.json 文件添加到 repo，并将 _workspace 添加到 .gitignore 列表即可：)。

虽然您的代码应该完全包含在您的 repo 中，但必须以某种方式引用依赖项（godep.json、package.json、git 子模块...您选择），仅此而已。 同样的策略适用于 npm、bower、apt 和所有其他包管理器。

你的 repo - 你的东西 + 对供应商库的引用（当然，如果可能，你不能引用 sourceforge zip 文件）。

正如@VonC 所说，我们不想对供应商库进行版本控制。

Answer 3

官方回答：

来自 GitHub 问题#131：

godep 的预期用途是供应商依赖关系并将 _workspace 目录提交给版本控制。请参阅#123 中链接的@kr 的提案文档（提案：http://goo.gl/RpYs8e）正如该提案中所讨论的，godep 曾经有一个模式（-copy=false），它支持不出售依赖项。我的猜测是自述文件中的模棱两可的语言可能是由于这个原因。此模式已被删除，如 #123 中所述。

这里还有godep作者谈论他的项目和背后的想法-Vendoring and Import Path Rewriting

个人意见：

我认为没有正确的方法。

提交供应商库确实看起来很尴尬，但它有它的优势：

• 您不依赖外部服务（GitHub 等）。 GitHub 出现故障，也许你有一些糟糕的公司政策阻止你使用它，也许存储库消失了或者它的历史被重写了，也许你在防火墙后面（暂存/构建服务器）等等。
• 每次对您的部门进行更新时，您都会很好地了解更改的内容。 这有助于更新到新版本，或者如果您筛选正在使用的代码，则只需跟踪更改。

最后由你来权衡利弊。就个人而言，每次我必须提交供应商代码时我都会畏缩，但在我的 Go 项目中我会这样做。至少现在是这样。

此外，Google 和 Facebook 等公司大多将所有内容保存在一个存储库中，其中包括供应商代码（或者我听说过）。

关于该主题的有趣文章： Go Package Management