如何自动在多个GitHub仓库间同步pyproject.toml文件？

针对你遇到的中心pyproject.toml同步问题，这里有几个比直接用GitHub Actions复制文件更高效的方案，各有适用场景：

1. 利用Git子模块（Submodules）实现依赖引用 #

这是Git原生的多仓库共享文件方案，不需要额外工具：

• 操作步骤：
  1. 在每个project-repo中执行git submodule add <central-repo-url> ./central-config，将中心仓库作为子模块引入
  2. 在项目构建/开发时，指定使用子模块内的pyproject.toml：比如Poetry可以用poetry install --config ./central-config/pyproject.toml，Setuptools可以通过修改setup.py读取该路径的配置
  3. 当central-repo的配置更新后，在project-repo中执行git submodule update --remote拉取最新版本，然后提交子模块的更新到项目仓库
• 优势：
  • 无需自动同步动作，完全由Git版本控制，可自主选择更新时机
  • 不会产生额外的CI触发（除非你主动提交子模块更新）
• 注意点：
  • 团队成员克隆项目时需要加上--recurse-submodules参数，或者克隆后执行git submodule init && git submodule update
  • 子模块的版本绑定到特定commit，需要手动更新才能获取最新配置

2. 改进GitHub Actions同步逻辑，跳过CI触发 #

如果你不想改变项目结构，直接优化现有Actions方案即可：

• 操作步骤：
  在同步pyproject.toml的提交信息中加入[skip ci]或[no ci]标签（GitHub官方支持的跳过CI标记）
  比如在Actions的提交命令里写：git commit -m "Sync pyproject.toml from central-repo [skip ci]"
• 优势：
  • 完全兼容现有工作流，无需调整项目结构
  • 彻底解决额外CI触发的问题，同步提交不会触发项目仓库的CI流水线
• 注意点：
  • 确保提交信息的标签格式正确，GitHub才能识别并跳过CI

3. 使用Git Subtree合并中心配置 #

Subtree是比子模块更易用的多仓库内容共享方案：

• 操作步骤：
  1. 在project-repo中执行git subtree add --prefix=central-config <central-repo-url> main，将中心仓库的main分支合并到项目的central-config目录
  2. 当中心配置更新时，执行git subtree pull --prefix=central-config <central-repo-url> main -m "Update central config [skip ci]"拉取最新内容并提交
• 优势：
  • 对团队成员更友好，不需要了解子模块的特殊操作，和普通Git仓库使用方式一致
  • 可以结合Actions自动执行拉取和提交，同样通过[skip ci]避免CI触发
• 注意点：
  • 项目仓库的提交历史会包含中心仓库的提交记录，可能会让历史稍显复杂

4. 利用Python配置工具的继承/包含特性 #

如果你的项目使用Poetry、Hatch等现代Python构建工具，可以直接利用它们的配置继承能力：

• 操作步骤：
  1. 在central-repo中维护一个基础的pyproject.toml（只包含共用配置）
  2. 在每个project-repo的pyproject.toml中，使用工具支持的include或extends语法引用中心配置：
     比如Poetry可以用include = ["../central-config/pyproject.toml"]（如果是子模块/Subtree的目录结构），部分工具也支持远程URL引用（需确认工具兼容性）
• 优势：
  • 项目配置文件只需要保留项目特有内容，减少冗余
  • 无需手动同步文件，工具会自动读取共用配置
• 注意点：
  • 不同工具的配置继承语法有差异，需要根据使用的构建工具调整
  • 如果引用远程URL，部分工具可能需要额外插件或配置支持

内容的提问来源于stack exchange，提问作者антон еремин