默认情况下，如果在您的 GOPATH 上找不到依赖项，Go 通过获取 master (github) 或默认 (mercurial) 中的最新版本来拉取导入的依赖项。虽然这个工作流程很容易掌握，但严格控制却变得有些困难。因为所有软件更改都会带来一些风险，所以我想以一种可管理和可重复的方式降低这种潜在更改的风险，并避免无意中发现依赖项的更改，尤其是在通过 CI 服务器运行干净构建或准备部署时。
我可以固定（即锁定或捕获）包依赖项的最有效方法是什么，这样我就不会发现自己无法重现旧包，或者更糟糕的是，在我即将发布时意外损坏？
- - 更新 - -
有关 Go Packaging 当前状态的附加信息。虽然我最终（截至 7.20.13）在第 3 方文件夹中捕获依赖项并管理更新（ala Camlistore），但我仍在寻找更好的方法......
此外，请务必查看go 1.5 供应商/实验，以了解 go 在未来版本中如何处理该问题。
您可能会发现Camlistore的做法很有趣。
请参阅第三方目录，尤其是update.plandrewrite-imports.sh脚本。这些脚本更新外部存储库，在必要时更改导入，并确保外部存储库的静态版本与 camlistore 代码的其余部分一起签入。
这意味着 camlistore 具有完全可重复的构建，因为它是自包含的，但第三方组件可以在 camlistore 开发人员的控制下进行更新。
有一个项目可以帮助您管理依赖项。检查gopack
戈迪普
去年年初（2014 年）我开始使用godep并且对它非常满意（它满足了我在原始问题中提到的问题）。我不再使用自定义脚本来管理依赖项的供应，因为godep只是负责它。无论时间或机器的封装状态如何，它都非常适合确保不会引入漂移。它与现有的机制一起工作，并基于 Godeps/godeps.jsongo get引入了 pin ( godep save) 和 restore ( ) 的能力。godep restore
看看这个：
在 go 中没有内置的工具。但是，您可以自己在本地磁盘或云服务中分叉依赖项，并且只有在您审查它们后才合并上游更改。
第 3 方存储库完全在您的控制之下。'go get' 克隆提示，你是对的，但你可以自由检出 cloned-by-go-get 或 cloned-by-you 存储库的任何修订。只要您不执行“go get -u”，就不会触及已经位于硬盘上的第 3 方存储库。
实际上，默认情况下，您的外部、本地克隆的依赖项总是被锁定。