go - 供应 Golang 共享存储库

Question

尝试从旧版 Godeps 工作流迁移到官方支持的 Golang vendor 解决方案。

场景:

Repo A===
         \
           ========> Repo C (shared library code)
         /  
Repo B===

对于中型(大约 5-10 名成员)工程师团队，我可以为 Repo A 和 Repo B vendor Repo C 选择什么最佳工作流程？能力各异的工程师，其中大多数可能根本不需要知道这方面的细节？

我目前正在为此使用 govendor。我宁愿不切换，但如果有一种工具可以提供更好的工作流程，我会这样做。

这需要与运行构建的 CI 服务器集成。我可以想到 3 种情况:

vendor repo C 到 A 和 B:

• 优点:

  • 可重现的构建
  • 与 CI 轻松集成

• 缺点:

  • 手动且容易出错 - 很容易供应不正确的代码
  • 工程师需要充分了解 vendor 的工具和方法

Symlink Repo C 主干分支到 A 和 B 的 vendor 文件夹中:

• 优点:

  • 工程师不需要了解 vendor 工具
  • 开发人员维护成本低

• 缺点:

  • 构建不可(轻易)重现
  • 在构建中包含不应发布的代码的可能性
  • 不太灵活(Repo A 和 Repo B 不能有不同版本的 C)

将 Repo C 作为 git 子模块或子树包含在 Repo A 和 Repo B 中(无论是否使用 vendor ):

• 优点:

  • 工程师不需要了解 vendor 工具
  • 设置简单
  • 减少维护
  • 可重现的构建

• 缺点:

  • 必须使用 git 子模块或子树

令人惊讶的是，在互联网上几乎找不到关于这个问题的资料。有一些惯用的方法吗？我敢肯定还有其他方法可以做到这一点；我错过了什么？

Answer 1

我建议使用具有版本约束的基于 list 的方法。

Project A == Manifest
             |- Repo A@~1.0.1
             |- Repo B@~1.0.1

Repo A == Manifest
             |- Repo C@~1.0.1

Repo B == Manifest
             |- Repo C@~1.0.5

Repo C == Manifest empty

这将解析为

Project A == Resolved Manifest
             |- Repo A@1.0.1
             |- Repo B@1.0.1
             |- Repo C@1.0.5

哪里~1.0.1表示 >=1.0.1 <1.1.0 .

如您所见，B 和 A 对 C 的依赖是独立的，但在项目中它们被正确解析。

如果 A 和 B 定义了对 C 的不兼容依赖项，则应发生错误，因为项目不应是可构建的。

您可能更喜欢使用插入符号 ^而不是波浪线 ~ , ^1.0.1 -> >=1.0.1 < 2.0.0 .

请注意，您并非被迫使用波浪号和插入符等“助手”，您可以定义明确的版本范围。

您应根据您给予远程作者正确升级其版本号的信心水平来决定应用哪个约束。

最后，您可以使用 glide 为您解决。

从 Repo C 开始，假设您已经标记了 repos，运行 glide init , git commit -am 'glide init' , git push

repo A，glide init , glide get git@repo.com/repoc , git commit -am 'glide init' , git push

repo B，glide init , glide get git@repo.com/repoc , git commit -am 'glide init' , git push

最后，项目 A，glide init , glide get git@repo.com/repoa , glide get git@repo.com/repob , git commit -am 'glide init' , git push

要重新安装项目，glide install , go build .

为了在执行远程安装时跳过 glide install 命令，没有什么能阻止您将 ProjectA 与它的 vendor 文件夹打包在一起。

但是您通常不想为开发环境提交 vendor 文件夹。您通常会添加 vendor/给你的.gitignore文件并运行 glide install或 glide update .

预计开始时会遇到一些困难，通过那一步，事情就会成功。

一旦您跳转到该工作流程，请注意，您必须在您的存储库中添加所有更改。

当您同时处理项目 A 和存储库 B 以实现可行的更改时，这就是过时软件，因此在这种情况下，不要将存储库 vendor 提供给项目 A(您可以保留 list 定义，但将存储库文件夹放入 vendor/)，将 repoB 安装为 go模块与 go get命令。这样做，更改会在重建时立即生效。更改集完成后，浏览每个存储库并适本地碰撞它们。

最后，您可能想使用版本缓冲器来帮助您快速完成它，碰巧我做到了 one供我个人使用。

希望这对您有所帮助。