在我工作的公司中，我们有几个用Go编写的后端系统，一些代码在它们之间共享。后端系统需要单独部署，可能在不同的机器上。所有这些项目仍在积极发展和经常变化。
我们正在努力想出一个管理我们的git存储库以及它们之间依赖关系的好方法。
目前我们有一个共享代码存储库，让我们称之为后端共享。然后我们为每个后端系统都有一个单独的存储库，让我们将它们称为backend1和backend2。反过来，每个后端在后端共享上都有Godep依赖。
据我所知，Golang中依赖管理的首选方法是通过vendored，根据该方法将所有依赖项复制到/ vendor目录中，并应检入版本控制。这样，所有依赖项都将锁定到特定版本。
这适用于我们的外部依赖项，但是对于后端共享的内部依赖，它变得非常麻烦，因为开发人员必须同时对特定后端系统和后端进行更改并不罕见-共享。
现在，如果对开发人员的GOPATH中驻留的后端共享进行了更改，那么后端1（也在GOPATH中）将无法看到该更改，因为backend1将首先查看后端的陈旧副本 - 在其/ vendor目录中共享。
因此，我们要么必须重新供应backend1才能复制后端共享的新版本，否则我们必须暂时从/ vendor目录中删除后端共享，以便导入指向版本在GOPATH里面。这两个选项都有可能变脏，我不确定它们是否是Go的用途。
我的问题是，是否有更好的方法来保留我们当前的存储库并同时简化多个项目的开发？
或者我们应该将所有存储库合并为一个存储库，因为现在它们的开发生命周期相互交织，即使依赖性明确的后端1和后端2是分开的吗？
我们没有从包含backend1，backend2和backend-shared的单个存储库开始的主要原因是backend1和backend2必须单独部署，所以我们希望他们的代码也是物理上分开的。
答案 0 :(得分：0)
也许govendor可以满足您的需求。它可以通过以下命令添加一个依赖包而不是所有依赖包：
cd your_project_path
govendor init // run only first time
govendor add path_to_external_package // like github.com/astaxie/beego
答案 1 :(得分：0)
我认为Glide对你来说效果更好，因为你可以安全地忽略销售内部共享包并使用GOPATH中的版本（如果你的backend1和backend2必须使用最新版本编译，这将有效）后端的版本，如果不是这种情况，你可能更喜欢销售你的软件包并使用SemVer标签来评论后端发生的重大变化，然后锁定适用于每个项目的版本。）
glide.yaml文件命名您正在销售的软件包，在那里您可以添加要忽略的软件包
答案 2 :(得分：0)
我不想沉迷于最喜欢的依赖工具，但是我会提到Glock（https://github.com/robfig/glock）管理依赖关系而不需要'vendoring'本身。我在我自己的项目中使用它，我也控制上游回购。出于同样的原因，它可能适合您的公司。
我也有一个完全不同的建议。对所有项目使用单个 repo，每个项目都有一个子目录。虽然这在整体代码库仍然很小时是最好的，但它确实允许共同开发组织比拥有许多回购更好。
例如，任何开发人员都可以分支（当然包含所有内容）并处理相互关联的组件，可能涉及重大变更。当它完成并且稳定时，它可以一次性合并。这种方法从来没有任何“竞争条件”，因为提交是原子的。