模块依赖问题共同开发两个独立的 go 模块

一分耕耘，一分收获！既然打开了这篇文章《模块依赖问题共同开发两个独立的 go 模块》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

我正在创建一个小型实用程序，我们称之为a，为此我需要对另一个go项目进行一些小更改，我们称之为b。

首先，我将 b 分叉为 b_forked，并创建了所需的 pr。作者还没审，没关系，不着急。

但我想暂时让 a 使用我的版本 b_forked。更重要的是，我希望能够共同开发两者（编辑文件并让它们接受彼此的更改，而不是让 a 坚持 b 的版本>/b_forked）。

所以我编辑了a来导入b_forked，并在我的~/projects/a/go.mod中编写了以下内容：

module a

go 1.15

require (
    ... # other packages
)

replace b_forked => ../b_forked

在b_forked中，我输入了以下~/projects/b_forked/go.mod（版本号是由go自动生成的）：

module b_forked

go 1.15

require (
    b v0.0.0-00010101000000-000000000000
    ... # other packages
)

replace b => ./

在我的 b_forked 版本中，我不想将代码中的所有 import b/... 替换为 import b_forked/... （因为我希望将更改包含在稍后向 b 提出 pr）。这就是我在这里使用 replace 规则的原因。

不知怎的，这不起作用，我不明白为什么。构建b_forked似乎有效：

$ cd ~/projects/b_forked
$ go build
$

但是当我尝试编译a时，我得到：

$ cd ~/Projects/A
$ go build

go: found github.com/janpfeifer/webcam in github.com/janpfeifer/webcam v0.0.0-00010101000000-000000000000
go: github.com/janpfeifer/[email protected] requires
        github.com/blackjack/[email protected]: invalid version: unknown revision 000000000000

• janpfeifer/webcam == b_forked
• blackjack/webcam == b
• b的版本号，即blackjack/webcam，是我构建b_forked时由go本身选择的

我可能误解了 go 模块的底层抽象（到目前为止，我在模块上花费的时间比在简单代码本身上花费的时间多得多）。有什么想法如何设置吗？也许有一种我不知道的更简单的滚动方式？

非常感谢！

解决方案

阅读答案和评论（thx @kostix，@volker）并进行实验后，对我来说最有效的方法是：

将B分叉为B_forked，并在B_forked中有2个分支：

• 分支b1是我用来创建github PR的分支。

• 在分支 b2 中，我将 B 的所有自导入更改为 B_forked。之后我使用b2与A共同开发。我 gitcherry-pick 将更改提交回分支 b1。

在A中，我导入了B_forked，并在go.mod中，我将版本设置为b2分支的HEAD，因此可以由其他人构建，而 PR 未进入存储库 B。

在开发过程中，我在 A 的 go.mod 中添加了一条从 B_forked 到其本地磁盘目录的 replace 规则，因此 <在A中立即可以看到strong>B_forked。

一旦引入 B 的 PR，我会将 A 的导入更改回 B。

如果您“分叉”包含 Go 包或 Go 模块的存储库，您将创建与原始版本完全无关的内容。根据详细信息，您甚至可能无法编译“fork”（甚至无法编译未修改的“fork”），并且“fork”可能无法工作。

经验法则：永远不要分叉 Go 包或 Go 模块。

您必须如上所述。 B_forked 与 B 完全无关。您必须重写所有导入或为所有导入添加替换指令。这里的“必须”这个词是经过精心挑选的：你真的必须，这里没有欺骗或耍小聪明，尤其是

行不通。这根本不是 Go 模块（或包）的工作方式。模块的标识基于其导入路径上的模块名称和包的标识（以其包含的模块名称为前缀）。

主要问题源于“分叉”。只是不要这样做！您无法在货叉上可靠且方便地工作。决不。任何替换指令魔法都无济于事。你不能分叉。

改为执行一个简单的 git clone。这样您就可以获得模块/包的正确副本。处理那个克隆。将替换指令添加到您的项目 A 中，指向您的本地克隆（不是“分叉”！）。像这样 B 仍然可以正确构建，不需要替换魔术或导入路径重写，并且 A 将拾取 B 的本地修改副本。

好的。对于 Github-PR，您需要一个分叉，但该分叉只需要存在于 Github 上。 执行以下操作：