我有一个git repo“ core”和“ project” repo，它使用“ core”作为依赖项。如果要更改“核心”模块的某些API及其在“项目”中的用法，我在gitlab中创建两个单独的请求。但是，如果“核心”包含API更改，那么我们的持续集成系统将无法在“核心”被合并之前测试“项目”。 我想要的是，“项目”测试的可能性将在“核心”的同一分支上进行。例如，如果我在“项目”和“核心”中创建了分支“功能42”，则“项目”测试将在“核心”的“功能42”分支上开始。
现在我们有机会在go模块上移动，但是很难总是在go.mod文件中指定直接提交哈希（很多可能会出错）。 看起来我们应该使用monorepo，但是我担心我们的项目可能会变得单一（考虑到我们没有非常合格的开发人员）。
我们如何组织持续集成？
P.S。同样，我们也不想在版本中使用标签，因为人们可以并行工作，而且很难始终保持非降级版本。
答案 0 :(得分：1)
您的go.mod文件可以指定依赖项的显式提交-即使该提交在分支上！ —只要提交实际上已发布到该存储库中即可。
因此，如果您在feature-42的{{1}}分支上发布功能并想在core中使用该功能，则可以在project内运行go get core@feature-42模块，那么您应该获得包含该功能的版本。
（{project命令通常知道如何将分支名称解析为特定的提交，因此您无需显式命名提交哈希。但是，go文件将记录一个pseudo-version和已解析的哈希。）
作为另一种选择，您可以在CI系统中添加一个go.mod命令，以使该go mod edit -replace模块的所选版本明确地替换为所涉及的分支。
话虽如此，听起来您切换到monorepo可能更简单，也许在repo根目录下只有一个core文件，以便所有内容都按照锁定步骤进行版本控制。以我的经验，避免Go项目变成整体的最好方法是使用internal packages，而不是单独的存储库。