我正在Go中编写一个项目，部署在heroku上，使用godeep管理依赖关系。
当我godep save时，我会得到一个列出我的依赖项版本的Godeps.json文件和一个复制了所有依赖项源的_workspace/目录。我宁愿不提交_workspace，所有这些代码都已经在github上了。Godeps.json似乎拥有我们在heroku构建包时go get版本锁定依赖项所需的所有信息。
一些消息来源建议提交完整的Godeps/目录，但其他人认为可能没有必要。
Godeep文档没有多大帮助：
这将把依赖项列表保存到文件Godesp/Godes.json中，并将它们的源代码复制到Godesp/_workspace中。仔细阅读它的内容，确保它看起来合理。然后将文件提交到版本控制。
Godes.json是文件吗？
官方答案：
来自GitHub第131期：
godep的预期用途是提供依赖关系，并将_workspace目录提交给版本控制。请参阅#123中链接的@kr的提案文件（提案：http://goo.gl/RpYs8e)正如该提案中所讨论的，godeep曾经有一种模式（-copy=false），支持不出售依赖项。我的猜测是，Readme中模棱两可的语言可能就是由于这个原因。该模式已被删除，如#123中所述。
这里还有godep作者谈论他的项目和背后的想法-自动售货和导入路径重写
个人意见：
我认为没有正确的方法。
提交供应商libs看起来确实很尴尬，但它有它的优势：
- 您不依赖外部服务（GitHub等）。GitHub出现故障，也许你有一些可怕的公司政策阻止你使用它，也许存储库消失了，或者它的历史记录被重写了，也许你在防火墙后面（暂存/构建服务器），等等
- 每次你的deps有更新时，你都会很好地了解发生了什么变化。这有助于更新到新版本，或者如果您筛选正在使用的代码，只需跟踪更改
最后由你来权衡利弊。就我个人而言，每次我必须提交供应商代码时，我都会感到尴尬，但在我的Go项目中，我会这样做。至少目前是这样。
此外，像谷歌和脸书这样的公司大多将所有内容都保存在一个存储库中，其中包括供应商代码（或者我听说过）。
关于该主题的有趣文章：Go Package Management
godeep将需要json文件来读取依赖关系，如update.go所示
因此，需要对该文件进行版本控制。
但是Godeep会填充godep/_workspace的内容，这意味着它是一个"生成的"内容：您不需要对其进行版本化。
只需将Godes.json文件添加到repo，并将_workspace添加到.gitignore列表：）。
虽然你的代码应该完全包含在你的repo中，但依赖项必须以某种方式被引用（godep.json、package.json、git子模块……你可以选择），仅此而已。同样的策略也适用于npm、bower、apt和所有其他包管理器。
你的repo-你的东西+对供应商库的引用（当然，如果可能的话，你不能引用sourceforge zip文件）。
正如@VonC所说，我们不想对供应商的libs进行版本化。