我们有两个版本的go模块，由不同的人托管。我们称它们为example.org/devproject和company.com/project。显然，不同的程序会根据需要通过example.org或company.com维护版本，通过适当的不同导入路径来导入两个项目。由于模块具有许多内部软件包，因此源文件本身在许多import语句中都包含了对自己模块名称的引用。
我的问题是example.org如何使company.com尽可能容易地从我们的git存储库中提取，因为现在直接进行git pull会弄乱导入语句。请注意，堆栈溢出对此之前的模块有类似的问题。但是，此问题专门涉及使用go 1.11或更高版本的go.mod文件的项目，因此请不要将我引至非模块答案或建议不使用go模块，因为这是一个不同的问题。
我尝试了以下操作，但不幸的是效果不佳：
在module self文件中使用一些抽象模块名称，例如go.mod，然后添加replace self => example.org/devproject。这样内部软件包就可以import "self/subpackage"，并且仅一个replace行就需要在存储库之间进行更改。但是，这意味着包括项目在内的所有项目都需要使用replace指令，并且我们需要说服company.com更改其相对于“自我”的所有导入，这不太可能。更重要的是，这完全破坏了go get，可能不是一个好主意。
使用半自动化脚本来维护git分支pull-me，该分支始终恰好是master之前的一个提交，但已将所有导入路径和go.mod文件固定为company.com。这是我们目前正在执行的操作，但很烦人，因为脚本不知道如何解析源代码，因此请在各处到处用example.org/devproject盲目替换company.com/project，这意味着不能保证仅仅因为{ {1}}的作品master也将如此。我们不知何故无法使pull-me在gopath之外的go模块中工作（它将更改包语句，但不会更改导入，这是棘手的一部分，并且不会递归到所有子包中。） / p>
创建一个伪造的gopath，将master分支复制到其中，使用gomvpkg移动内容，然后使用修改的导入路径将文件复制回去，然后删除伪造的gopath。我无法100％排除这种情况，但是在gomvpkg一直拒绝做正确的事之后，我放弃了，但我感到沮丧的是，从概念上讲如此简单的事情很难在实践中进行。
还有其他我们应该考虑的解决方案吗？是否有诸如gomvpkg之类的工具能够理解go模块并重写导入路径，而无需同时尝试在gopath中移动内容？
可能已经很清楚了，这里的动态是example.org更有动力将事情上游到上游，而company.com则是从我们这里撤走，因此理想情况下，大多数跳车都发生在example.org一侧，并且可能会向company.com发出一次简单的非侵入式请求，以完成这项工作。