GitHub Fork UI分支后如何关联引入其他Fork的引擎仓库

完全不用局限于只能Fork单个仓库再手动复制代码，你要的目录结构可以正常实现，根据你后续的维护需求选下面两种方案就行：

• 方案1：以UI优化版Fork作为主仓库，搭配Git子模块关联引擎Fork
  这个方案最适配你当前的场景，毕竟UI版本开发进度高，后续对齐UI改动的成本最低：
  1. 先在GitHub上Fork那个UI优化版本的仓库，作为你自己的主开发仓库，克隆到本地
  2. 删掉主仓库里所有旧引擎相关的引用文件，把现有UI版本的所有代码统一移动到original(forkedUI)目录下
  3. 在本地仓库根目录执行命令，把更新了底层引擎的那个Fork作为子模块添加进来，指定存到original(forkedENGINE)目录：
     git submodule add <引擎Fork的仓库地址> original(forkedENGINE)
  4. 根目录放你自己的新开发文件，提交所有改动推送到你自己的远程仓库就完成初始搭建了
  • 后续维护注意：要同步引擎Fork的更新时，直接进original(forkedENGINE)目录拉取对应上游提交即可；要同步原UI版本的新提交时，给主仓库添加上游源拉取对应内容，再把更新的文件同步到original(forkedUI)目录就行。这个方案的优势是两个Fork的提交历史完全独立，同步更新时冲突概率低；缺点是子模块有少量特殊操作逻辑，新手刚接触容易忘，后续克隆你这个仓库的时候要加--recurse-submodules参数才能把引擎目录的代码完整拉下来。
• 方案2：用Git Subtree代替子模块，降低新手操作门槛
  整体搭建逻辑和方案1一致，区别是不用子模块，而是把引擎Fork作为子树导入到主仓库的original(forkedENGINE)目录。导入完成后引擎目录的代码和仓库里的普通文件没有任何区别，不需要记子模块的特殊操作命令，对新手更友好。缺点是后续同步引擎Fork的更新时，命令比普通拉取稍复杂，且两个Fork的提交历史会合并到主仓库的提交记录里，历史看起来会杂一些。

补充说明：如果你列的目录结构只是示意，实际需求是把两个Fork的改动整合到同一份可运行代码里（不拆分两个独立的original目录存放），那操作更简单：还是先Fork UI版本作为主仓库，把引擎Fork添加为额外的远程源，拉取引擎分支到本地，解决完代码冲突后把引擎更新的提交合并到UI分支即可，不需要拆分目录存放。

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