问在主测试环境中有子模块的CI/CD和到生产环境的稳定分支的最佳GIT工作流是什么？

EN

最后，我们使用了子模块，我发现您可以选择通过.gitmodules文件通过这是如此的帖子添加分支名。

因此，我将这段代码的最后一行添加到我的所有主分支中。

[submodule "SubmoduleTestRepo"]
    path = SubmoduleTestRepo
    url = https://github.com/jzaccone/SubmoduleTestRepo.git
    branch = master

当将一个主服务器合并到稳定时，我只需将其更新为

[submodule "SubmoduleTestRepo"]
    path = SubmoduleTestRepo
    url = https://github.com/jzaccone/SubmoduleTestRepo.git
    branch = stable

当然，这确实意味着，如果对嵌套子模块所做的更改，我首先需要将主分支合并到great的稳定分支，但是尽管如此，我还是保留了我习惯的伟大的调试和编辑流程，并且我可以在多个其他项目中使用相同的基础项目。这两件事对我们的工作流程都是至关重要的。

谢谢你在正确的方向上帮助我。

老实说，在处理子模块时，我总是很难找到可以使用的好工作流，特别是因为您指出了以下原因：

但是，为了使这一工作，我们需要改变的子模块，每次我们合并母版稳定。

我不喜欢为了实现日常变化而在一堆回购中协调大量的合并。主回购模块和子模块是否经常串联变化？子模块是否也用于其他项目，还是仅由项目在主回购中使用？你愿意考虑摆脱子模块，只做一个回购吗？我认为，如果您放弃子模块，您的工作流程将像您所描述的那样清晰。

在某些情况下，子模块是必需的，但是如果您决定它们增加的工作量和复杂性要比价值多，那么就可以在保留历史的同时将子模块滚动到您的主回购中。在主回购中，完全删除子模块，并提交该子模块。然后，在子模块repos中，将repo的内容移动到一个名为子模块的文件夹中，并提交该文件夹。最后，返回主回购，将子模块repos添加为remotes，然后将任何您命名的远程/主程序合并到您的主回购分支中，并使用--allow-unrelated-histories选项。

我有两个共享代码的要求

1. 我自己的构建是可重复的。
2. 我并没有意识到新的bug或破坏的更改/我可以积极地选择何时升级到新版本的依赖项。

这些通常通过锁定依赖的版本和某种版本控制方案来实现。Nuget在这里很好，因为除非我启动一个更改，否则我总是会得到相同版本的二进制文件，并且它遵循语义版本化，所以我大致知道我得到了什么级别的更改。

仅仅在我的脑海中跟踪一个稳定的依赖分支是不够的。我认为稳定是被证明的，一点也不改变。

Git子模块显然可以跟踪除了主人以外的分支..。但不要提交散列，这将是防止意外变化的理想选择。

也许一个带有符号的nuget包会起作用(用于调试)？