Golang内部依赖管理

Question

在我工作的公司，我们有几个用Go编写的后端系统，其中一些代码是在它们之间共享的。后端系统需要单独部署，可能部署在不同的机器上。所有这些项目仍在积极开发中，并经常发生变化。

我们正试图想出一个好的方法来管理我们的git存储库和它们之间的依赖关系。

目前我们有一个用于共享代码的存储库，让我们将其称为后端共享。然后我们为每个后端系统都有一个单独的存储库，让我们称它们为backend1和backend2。反过来，每个后端都有一个Godep对backend-shared的依赖。

据我所知，Golang中的依赖项管理的首选方法是通过供应商，根据这种方法，所有的依赖项都被复制到/vendor目录中，并且应该签入到版本控制中。这样，所有依赖项都锁定到特定版本。

这对于我们的外部依赖很好，但是对于内部对后端共享的依赖，它变得相当麻烦，因为开发人员必须同时对特定的后端系统以及后端共享进行更改的情况并不罕见。

现在，如果对驻留在开发人员的GOPATH中的后端共享进行了更改，该更改在backend1 (也在GOPATH中)中是不可见的，因为backend1将首先查看其/vendor目录中的backend-shared的陈旧副本。

因此，我们要么为了复制backend-shared的新版本而重新提供backend1，要么为了让导入指向GOPATH中的版本而临时从/vendor目录中删除backend-shared。这两个选项看起来都可能很脏，我不确定它们是否是Go应该使用的方式。

我的问题是，是否有更好的方法来保留我们当前的存储库，并同时简化多个项目的开发？

或者，我们是否应该将所有存储库合并为一个存储库，因为目前它们的开发生命周期相当纠缠在一起，即使依赖项明智的backend1和backend2是分开的？

我们没有从包含backend1，backend2和后端共享的单一存储库开始的主要原因是backend1和backend2必须分开部署，所以我们希望他们的代码在物理上也是分开的。

Answer 1

也许govendor可以满足你的需求。可以通过以下命令添加一个依赖包，而不是所有依赖包：

cd your_project_path
govendor init                         // run only first time
govendor add path_to_external_package // like github.com/astaxie/beego

Answer 2

我认为Glide更适合你，因为你可以安全地忽略你的内部共享包的提供，而使用GOPATH中的版本(如果你的backend1和backend2必须用最新版本的后端编译，这将会起作用，如果不是这样，你可能更喜欢提供你的包，并使用SemVer标签来注释在后端所做的破坏性更改，然后锁定到每个项目的工作版本)。

glide.yaml文件命名您要提供的包，您可以在其中添加要忽略的包

glide.yaml docs

Answer 3

我不想沉迷于喜欢的依赖工具，但我会提到Glock (https://github.com/robfig/glock)，它管理依赖本身而不需要‘提供’本身。我在我自己的项目中使用它，在那里我也控制上游repos。出于同样的原因，它可能非常适合您的公司。

我还有一个完全不同的建议。对所有项目使用单个存储库，每个项目都有一个子目录。虽然当整体代码库仍然很小时，这是最好的，但它确实允许co-development组织得比拥有许多代码库更好。

例如，任何开发人员都可以分支(当然包含所有内容)并处理相互关联的组件，可能涉及破坏更改。当它完成并稳定后，它可以一下子合并回来。这个方法永远不会有任何“竞争条件”，因为提交是原子的。