复制粘贴修改自持header-only依赖后如何同步代码并选型依赖管理方案

不要手动粘贴文件逐行diff，用git本身的能力自动识别所有本地改动，效率比人工核对高10倍以上：

• 克隆原Module的官方仓库到本地临时目录，切出一个临时同步分支，例如 sync-local-fork
• 把MainProject里经过长期修改的Module本地副本，完整覆盖临时目录中原仓库的对应文件
• 在临时目录执行 git add . && git commit -m "Sync all forked changes from MainProject"，此时git自动生成的diff就是所有跨月累积的本地改动，不需要人工逐行比对
• 逐行筛查diff内容，删掉嵌入在Module代码里的MainProject专属硬编码路径、临时调试代码等非通用改动，清理完成后推送到Module仓库的远程同步分支
• 把清理后的同步分支合并回Module的主开发分支，打一个对齐的基线tag（例如 fork-aligned-v0.2），两边的代码基线就完成了完全对齐，历史分叉问题直接解决

针对“双仓库自托管、双向高频修改、header-only、现代CMake工程”的场景，直接拆解三个候选方案的实际适配性：

• git submodule
  本来就是为跨仓库独立开发场景设计的机制，对header-only零编译成本的库适配度极高。很多人觉得它难用，本质是没有根据开发场景调整用法：不要绑定远程的版本tag，直接让submodule跟踪Module仓库主开发分支的最新提交即可，日常改代码不需要切换版本、不需要发版，拉到本地的就是最新的开发代码。
• git subtree
  对不熟悉git操作的使用者更友好，拉取主工程代码时不需要额外的递归参数。但它的双向同步命令非常繁琐，每次要把主工程里嵌入的Module改动回灌到Module独立仓库时，需要输入很长的固定参数命令，高频双向开发时的操作成本远高于submodule，不适合需要频繁修改依赖的开发场景。
• C++20 modules
  这是语言层面的编译单元优化机制，解决的是传统头文件反复解析导致的编译速度问题，完全不涉及跨仓库的代码同步、依赖拉取逻辑，和git层面的依赖管理方案解决的问题没有任何重叠，根本不能作为依赖管理方案的候选。

之前尝试用CMake管理依赖失败，大概率是从一开始就走了“Module先安装、主工程find_package”的流程，要求每次改完Module必须走安装、版本号更新、查找依赖的冗长流程，在赶交付的节奏下完全不可行。正确的现代CMake配置完全可以省略这些步骤：

• Module仓库侧：在CMakeLists中定义标准的INTERFACE导出目标，写清楚头文件的包含路径，不需要写任何安装脚本
• MainProject侧：用git submodule把Module仓库拉到本地的 third_party/Module 目录，CMake中直接通过 add_subdirectory(third_party/Module) 引入，主工程目标通过 target_link_libraries(MainProject PRIVATE Module::Module) 关联，全程不需要find_package
• 日常开发没有额外流程成本：
  • 要改Module功能时，直接进入MainProject下的 third_party/Module 目录修改代码，改完直接在该目录提交、推送到Module的远程仓库
  • 回到MainProject根目录，提交一次submodule的指针更新，把MainProject关联到Module最新的提交即可
  • 整个过程没有复制粘贴、没有版本发布流程、没有本地安装步骤，改完立刻可以在主工程编译测试，完全适配赶开发节点的节奏

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