1

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

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

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

据我了解，Golang 中依赖管理的首选方法是通过 vendoring，根据该方法，所有依赖项都被复制到 /vendor 目录中，并且应该检查到版本控制中。这样，所有依赖项都锁定到特定版本。

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

现在，如果对位于开发人员的 GOPATH 中的 backend-shared 进行更改，则该更改在 backend1（也在 GOPATH 中）内不可见，因为 backend1 将首先查看其内部的 backend-shared 的陈旧副本/供应商目录。

因此，我们要么必须重新供应 backend1 以复制新版本的 backend-shared，要么我们必须暂时从 /vendor 目录中删除 backend-shared 以便导入指向 GOPATH 中的版本. 这两个选项都感觉可能很脏，我不确定它们是否是 Go 的本意。

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

或者我们是否应该将所有存储库合并为一个，因为即使依赖明智的后端 1 和后端 2 是分开的，它们的开发生命周期现在也是相互交织的？

我们没有从包含 backend1、backend2 和 backend-shared 的单个存储库开始的主要原因是 backend1 和 backend2 必须单独部署，因此我们希望它们的代码也物理上分开。

4

3 回答 3

0

不想过多地沉迷于最喜欢的依赖工具，但我会提到 Glock ( https://github.com/robfig/glock )，它管理依赖而无需“供应”本身。我在我自己的项目中使用它，我也控制上游存储库。出于同样的原因，它可能非常适合您的公司。

我也有一个完全不同的建议。为所有项目使用一个repo，每个项目都有一个子目录。尽管这在整体代码库仍然很小的情况下是最好的，但它确实比拥有许多 repos 更好地允许共同开发组织。

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

于 2017-04-29T23:38:40.633 回答
0

我认为Glide更适合您，因为您可以放心地忽略供应内部共享包并使用 GOPATH 中的版本（如果您的后端 1 和后端 2 必须使用最新版本的后端编译，如果不是，这将起作用在这种情况下，您可能更喜欢出售您的包并使用 SemVer 标签来标记后端所做的重大更改，然后锁定到适用于每个项目的版本）。

glide.yaml 文件命名您正在销售的软件包，您可以在其中添加要忽略的软件包

glide.yaml 文档

于 2017-04-29T16:53:55.073 回答
0

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

cd your_project_path
govendor init                         // run only first time
govendor add path_to_external_package // like github.com/astaxie/beego
于 2017-04-29T12:47:29.413 回答