同步Git Fork并添加自定义GitHub Actions且不污染上游贡献

一、同步上游分支同时运行自定义GitHub Actions #

方案1：用独立分支存储CI配置 #

• 创建专门的分支（比如github-ci-config），将所有.github/workflows/下的CI配置文件放到该分支，此分支不参与与GitLab上游的同步。
• 配置wei/git-sync时，仅指定同步上游的main和dev分支到复刻仓库的对应分支，不包含CI配置分支。
• 在github-ci-config分支的workflow文件中明确触发规则，覆盖需要执行CI的分支：

on:
  push:
    branches:
      - main
      - dev
      - 'feature/**' # 匹配所有基于main/dev创建的特性分支
  pull_request:
    branches:
      - main
      - dev

这种方式下，上游同步操作不会影响CI配置，同时所有目标分支的代码变动都能触发自定义CI。

方案2：利用组织/仓库级工作流（GitHub Enterprise支持） #

若你的GitHub Enterprise版本支持，直接在组织或仓库设置中定义全局工作流模板，无需将.github/workflows/目录放到代码分支里。工作流配置存储在GitHub系统中，与代码分支完全独立，只要分支符合触发规则（如main、dev、feature分支），就会自动执行CI。

二、确保贡献回上游不含自定义GitHub Actions #

1. 严格分支开发规范 #

• 所有开发工作必须基于复刻仓库中已同步上游的main或dev分支创建特性分支，开发过程中绝对不要修改.github/目录下的任何文件。
• 提交代码时，用git add指定仅添加业务代码文件，避免误加CI配置。

2. 前置校验拦截 #

在复刻仓库的CI中添加校验步骤，当特性分支推送时，检查是否存在.github/目录的改动，若有则直接终止CI并报错：

jobs:
  check-ci-config:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check for .github directory changes
        run: |
          if git diff --name-only HEAD~1 | grep -q "^.github/"; then
            echo "Error: Do not commit changes to .github directory in feature branches!"
            exit 1
          fi

3. 清理误提交的补救方法 #

如果不小心把CI配置的改动混入了特性分支，用变基清理提交：

git rebase -i upstream/main

在交互式变基界面中，删除或修改包含.github/改动的提交，确保最终推送到上游的提交仅包含业务代码修改。

三、无需将Actions纳入分支的执行方式 #

除了组织/仓库级工作流，最实用的是全局模板方案：

• 进入GitHub Enterprise的仓库设置，找到「Actions」→「Workflows」→「Workflow templates」
• 创建通用CI模板，设置触发分支为main、dev和feature/**
• 应用该模板到当前仓库，后续所有符合条件的分支变动都会自动触发这个模板定义的CI流程，代码分支中完全不需要存在.github/目录。

四、场景最佳实践总结 #

1. 配置与业务分离：优先使用组织/仓库级工作流，其次用独立分支存储CI配置，彻底避免CI配置和业务代码的耦合。
2. 自动化同步+分支保护：用wei/git-sync定时同步上游main/dev，同时给这两个分支开启保护规则，禁止直接推送，确保它们始终和上游一致。
3. 开发流程标准化：要求所有特性分支必须基于同步后的main/dev创建，CI前置校验拦截违规提交，从源头避免配置泄露到上游。
4. 提交校验常态化：开发人员本地提交前，用git diff upstream/main -- . ':(exclude).github'检查改动范围，确保只提交业务代码。

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