模块依赖性问题共同开发了两个单独的go模块

如何解决模块依赖性问题共同开发了两个单独的go模块

我正在创建一个small utility，我们将其称为 A ，为此，我需要对另一个go project进行一些小的更改，将其称为 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/...（因为我希望将更改包含在PR中，以 B ）。这就是为什么我在这里使用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/webcam@v0.0.0-00010101000000-000000000000 requires
        github.com/blackjack/webcam@v0.0.0-00010101000000-000000000000: invalid version: unknown revision 000000000000

• janpfeifer/webcam == B_forked
• blackjack/webcam == B
• 当我构建 B_forked
时，go自己选择了 B 的版本号blackjack/webcam。

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

非常感谢！

解决方法

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

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

• 在分支 b1 中，我用来创建github的PR。

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

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

在开发过程中，我在 A 的go.mod中将 replace 规则从 B_forked 添加到其本地磁盘目录中，因此进行了更改在 A 中会立即看到 B_forked 中的内容。

进入PR到 B 后，我会将 A 的导入更改回 B 。

,

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

经验法则：从不派生Go包或Go模块。

在我的B_forked版本中，我不想将代码中的所有导入B / ...替换为import B_forked /...

您必须，如上所述。 B_forked与B完全无关。您必须重写所有导入或为所有导入添加replace指令。这里必须仔细选择“必须”一词：您真的必须，这里没有欺骗或聪明的地方，特别是

这就是为什么我在这里使用替换规则。

不起作用。那根本不是Go模块（或包）如何工作的。模块的标识基于模块名称和程序包在其导入路径上的身份（该路径以其包含的模块名称为前缀）。

主要问题来自“分叉”。只是不要那样做！您无法在叉车上可靠，方便地工作。没门。没有替换指令魔术会有所帮助。你一定不能分叉。

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

因为我希望以后将更改包含在对B的PR中

好的。对于Github-PR，您需要一个fork，但是此fork仅需要存在于Github上。 请执行以下操作：

1. 您已经克隆了B并进行了工作。保留那个。
2. Github GUI中的叉子B。
3. 将该派生添加为克隆的附加远程对象。
4. 要创建PR，请执行以下操作：从克隆副本推送到其他远程fork并创建PR。
5. 从不尝试编译“ fork”。 “叉子”仅存在于Github上以进行PR。您所有的工作都是在B的实际代码上完成的。