我的项目使用了一个 mercurial 存储库，并且是在 Linux 下开发的。它还依赖于我们希望与其他项目共享的“通用”库。我目前正在考虑的解决方案是将库放在一个 mercurial 子存储库中，并按照此处的建议创建一个“薄壳”存储库。
假设我的存储库如下所示：
project/
core/
common/
我不确定工作流程应该是什么样子。我应该什么时候承诺project？我是在其上创建功能分支，还是仅在子存储库中创建？当一个新功能需要对core和进行向后不兼容的更改时会发生什么common？
任何额外的提示将不胜感激。
我应该什么时候承诺项目？
由于项目存储库应仅包含子存储库（并跟踪其修订），因此当您签出核心或公共存储库的不同版本并且您永久想要使用它时，您应该（并且只必须）提交项目为您的项目。
我是在其上创建功能分支，还是仅在子存储库中创建？
您必须为项目存储库和要在其中实现该功能的存储库创建一个“功能”存储库。
如果你只 fork 项目 repo，它仍然会跟踪原始的 core/common。另一方面，您还需要 fork 项目 repo 以拥有一个包含所有需要的 subrepos 的完整工作环境。
另一种方法是，每个开发人员都有自己的项目存储库的永久分支，并跟踪他当前正在处理的功能存储库。
然后将为更改的子存储库创建拉取请求。
当新功能需要在核心和通用方面进行向后不兼容的更改时会发生什么
这意味着您将在两个存储库中执行/提交/推送这些更改并更新项目 shell 存储库中的跟踪版本（提交新的 shell 存储库状态并推送它）。
这会产生项目的工作版本。
当然，不能使用不兼容版本的核心或公共存储库。
听起来，无论如何都应该为通用存储库争取向后兼容性，因为它也可能用于其他项目。