如何实现PR合并后Github子文件夹自动同步至对应独立仓库

前置准备 #

• 先在主仓库的设置页找到Actions加密密钥配置入口，新增一个带全仓库读写权限的个人访问令牌（PAT）作为加密密钥，密钥命名为SYNC_PAT。注意GitHub默认提供的内置工作流令牌没有跨仓库推送的权限，必须使用自己生成的、覆盖两个关联独立仓库读写范围的PAT
• 提前确认两个独立仓库的默认分支名称（通常为main或master），保证后续推送目标分支和独立仓库的实际分支匹配，避免推送失败

工作流触发规则配置 #

在主仓库的.github/workflows/目录下新建同步工作流文件，配置触发规则为：

• 仅在主仓库默认分支收到推送时触发（也就是所有PR完成合并后的提交事件自动启动工作流）
• 工作流运行时自动检测两个子目录的变更状态，没有变更的目录直接跳过同步流程，减少无效运行

同步逻辑落地步骤 #

工作流运行时的执行逻辑按以下流程设计：

1. 拉取主仓库最新的合并后代码，获取本次提交与上一次提交的版本差异
2. 对两个目标目录分别执行变更检测：
   • 对「Project A」目录：通过git对比命令检查该路径下是否存在文件增删改
   • 对「Project B」目录：执行同样的路径变更检测逻辑
3. 对检测到有变更的目录执行同步：
   • 临时创建干净的工作分支，将主仓库中对应子目录下的所有文件复制到工作分支的根目录（适配独立仓库的根目录存储结构）
   • 配置Git提交身份，使用之前存储的SYNC_PAT完成跨仓库认证
   • 将工作分支的内容强制推送到对应独立仓库的默认分支，保证两边内容完全一致
   • 推送完成后清理临时工作分支，避免资源残留

踩坑规避提示 #

• 不要使用git submodule或硬绑定的git subtree实现关联，这类方式会导致独立仓库的提交历史反向侵入主仓库的版本线，破坏主仓库的提交整洁度
• 每次同步推送时附带清晰的提交标记，比如标注对应主仓库的提交哈希，方便后续追溯变更来源
• 同步时默认覆盖独立仓库的所有根目录文件，不要保留独立仓库中主仓库对应子目录不存在的额外文件，保证两边内容的强一致性
• 配置单向同步逻辑：不要开启独立仓库到主仓库的反向同步，否则会形成“独立仓库变更触发主仓库工作流、主仓库又触发独立仓库推送”的循环触发死循环

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