如果你正在下载某个类库在你的根存储库上创建一个vendor子目录。处理这件事就像在包目录上加一个前缀。举例来说，拷贝来自于github.com/user/dep的项目放到vendor/user/dep。在这之后，重写你所有的引入（import），及其相互关系。此时是很痛苦的，当剩下的内容需要go get兼容的时候，看起来最有效的方式是确保事实上可重新构建（actually-reproducible build）。值得注意的是，我们在实践中很少去下载类库，因此这个办法虽然麻烦却很有效。

如何在实际中拷贝一个依赖关系到你自己的存储库是另外一个热门的话题。最简单的方法是从一个克隆（clone）中手动复制文件，如果你不关心上游部门的推送，这可能是最好的答案。有些人使用git子模块，但我们发现它们非常违反直觉并难以管理（对许多 人来说也是这样，这是有记录的）。我们对于git子目录（的管理）已经很成功，他工作起来就像是子模块。还有大量的工具是用来自动处理这项工作的。现在，它看起来就像godep发展非常积极，而且还很值得研究。

构建与部署有其技巧性，因此它与你的操作环境耦合紧密。我要描述下我们的场景，因为我认为它是个好模型，但它可能无法直接应用到你的组织机构中。

就构建而言，我们通常直接使用 go build 来开发，以及一个 Makefile 用于剪裁官方构建。这主要是因为我们熟悉多种语言，并且我们的工具使用需要做到最小功能合集（最小公倍数）。并且，我们的构建系统始于一个空环境，也需要自备编译器（ Makefile 文件很难看！）。

对部署而言，对我们最大的吸引是无状态之于有状态。

我们主要部署无状态的服务，方式类似于 Heroku。

我有意让这些成为一种来自一个大组织在生产环境相对较长地运行Go 的经验报告。虽然这些都是有根据的意见，但他们仍然只是意见，所以请持保留态度。这就是说，Go 最大优势是它结构简单。最终的最佳做法是拥抱简单，而不是试图绕过它。