Github多仓库项目架构搭建及跨仓库依赖同步、贡献回流方案咨询

核心问题诊断 #

当前将core代码直接拷贝到mod1、mod2仓库的方案，将动态依赖关系转为静态代码副本，完全断开了core与下游模块的版本关联，是导致代码无法正常回流的核心原因。

问题1：core变更自动同步到mod1、mod2实现方案 #

第一步：替换静态副本为动态依赖 #

两种可落地的实现方式可选：

• 私有包托管方案：将core模块作为私有包发布到Github Packages，mod1、mod2在项目依赖配置文件中直接声明对core包的版本约束，无需在仓库中存储core的代码副本。
• Git Submodule方案：在mod1、mod2仓库中执行git submodule add <core仓库地址> core，将core作为子模块嵌入，仓库中仅存储core对应提交的哈希引用，而非完整代码。

第二步：配置自动同步逻辑 #

在core仓库的.github/workflows目录下新增触发工作流，当core主分支有新的合并提交时，自动执行以下操作：

1. 若使用私有包方案：自动构建并发布新版本的core私有包，同时给mod1、mod2仓库自动提交PR，更新依赖配置中的core版本号，CI校验通过后合并即可完成同步。
2. 若使用Git Submodule方案：自动给mod1、mod2仓库提交PR，更新子模块指向的core最新提交哈希，校验通过后合并即可完成同步。

问题2：衍生仓库关联与代码回流方案 #

基础仓库关联规则 #

mod1、mod2作为上游基础仓库，所有客户衍生仓库（例如mod1-project1）统一通过同组织内Fork的方式创建，默认保留与上游mod1/mod2的关联关系，无需额外手动配置上游地址。

双向代码流转流程 #

• 上游变更同步到衍生仓库：衍生仓库本地执行git pull upstream main即可拉取上游mod1/mod2的最新代码，也可配置Github Action定期自动同步上游变更。
• 衍生仓库业务代码回流：衍生仓库中修改mod1/mod2相关的业务代码后，可直接向上游mod1/mod2仓库提交PR，经评审合并后完成回流，所有依赖该基础仓库的衍生项目都可同步到该变更。
• 衍生仓库core代码回流：由于衍生仓库中的core仍然是指向核心core仓库的依赖/子模块引用，修改core代码后直接向核心core仓库提交PR，评审合并后会触发问题1中的自动同步逻辑，将变更同步到所有依赖core的模块，彻底解决core修改无法回流的问题。

优化后依赖流转逻辑 #

core（包/子模块引用） → mod1/mod2（上游基础仓库） → Fork生成 mod1-project1（衍生仓库）
mod1-project1 业务修改 → PR回流到 mod1/mod2
mod1-project1 core修改 → PR回流到 core

内容的提问来源于stack exchange，提问作者mbsouksu