企业官网建设流程全解析

任何人可编辑的网站：基于 GitHub 自动合并 PR 的协作建站思路

这次我们来看一个很有意思的 GitHub 项目：一个“任何人都可以通过 PR 自动合并来编辑”的网站。

这种模式其实很适合技术团队、开源社区、文档站点和知识库场景。传统 CMS 需要后台账号、内容审核、发布权限管控，而这个项目直接把编辑入口放到了 GitHub 上，用 Pull Request 作为修改途径，通过自动化机器人（如 GitHub Actions）检测 PR 状态并自动合并，让网站内容在几分钟内从提交到上线。

本文会拆解它的核心机制、搭建思路、自动合并 PR 的配置方式、批量任务处理和常见坑。

1. 核心能力速览

这套方案不需要额外开发一个完整 CMS，只要一个静态网站仓库配合 GitHub Actions 工作流，就能实现“人人可提交、提交即上线”的效果。

2. 适用场景与使用边界

这个项目解决的问题很明确：如果你想做一个允许公众参与编辑的网站，又不想自建用户系统和后台管理，那么 Git + PR 是最合适的技术路径。

适合用这个模式的地方包括：

1. 团队内部知识库。成员通过 PR 提交文档修改，不需要给所有人开放服务器权限。
2. 开源项目官网。社区贡献者直接改页面内容，维护者通过自动合并减少机械性操作。
3. 产品公告和更新日志。提交 PR 后自动发布，减少发布等待时间。
4. 教程和说明文档。读者发现错误后直接提 PR，降低贡献门槛。
5. 活动页面和报名信息。内容更新频繁，适合用 Git 流程管理。

使用边界要注意几个问题。首先，自动合并 PR 有风险，如果代码库中有敏感信息或配置文件，必须通过路径限制阻止非授权 PR 修改。其次，这个模式不太适合完全不做人工审核的场景。比较稳妥的做法是按文件路径区分：核心文件需要人工 review，content 目录下的文件可以自动合并。

从材料看，这个项目的核心是把 GitHub PR 的自动化能力直接作为网站内容协作的基础设施。对于已经有 GitHub 使用经验的团队，上手成本几乎为零。

3. 本地编辑与 PR 提交流程设计

虽然项目本身依赖 GitHub 云端流程，但本地环境仍然需要准备好 Git 容器，方便本地预览和提交测试。

如果你打算把这个仓库作为网站内容源，至少准备以下目录结构：

website-content/ ├── content/ │ ├── pages/ │ ├── posts/ │ └── docs/ ├── public/ ├── .github/ │ └── workflows/ │ └── auto-merge.yml ├── package.json └── README.md

关键的.github/workflows/auto-merge.yml就是自动合并且被触发器直接调用的地方。

4. 自动合并 PR 的原理与配置

这个项目最核心的机制是“PR 自动合并”。GitHub 本身不提供开箱即用的“任何 PR 都自动合并”的功能，因为这样会有安全风险。项目通常采用两种方式实现自动合并。

4.1 方式一：GitHub Actions 自动合并工作流

在仓库中新建.github/workflows/auto-merge.yml，让 Actions 监听pull_request事件，当 PR 满足条件时自动批准并合并。

配置示例：

name: Auto Merge Valid PRs on: pull_request: types: [opened, synchronize, reopened] permissions: contents: write pull-requests: write jobs: auto-merge: runs-on: ubuntu-latest timeout-minutes: 10 steps: - name: Check out repository source uses: actions/checkout@v4 - name: Check if only content files changed id: changed_files run: | # 获取 PR 变更文件列表 CHANGED=$(git diff --name-only origin/main...HEAD | tr '\n' ' ') echo "changed_files=$CHANGED" >> "$GITHUB_OUTPUT" # 只允许 content 目录下的变更自动合并，其他文件需要人工审核 SAFE_PATTERN='^content/' echo "$CHANGED" | grep -v "$SAFE_PATTERN" && echo "contains_non_content_files=true" >> "$GITHUB_OUTPUT" || echo "contains_non_content_files=false" >> "$GITHUB_OUTPUT" - name: Auto approve PR if: steps.changed_files.outputs.contains_non_content_files == 'false' run: | gh pr review "$PR_URL" --approve gh pr merge "$PR_URL" --merge --auto env: PR_URL: ${{ github.event.pull_request.html_url }} GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

这段代码做的事情是：

1. PR 打开或有新提交时触发。
2. 检出代码，检查变更文件是否都在content/目录内。
3. 如果是安全的内容变更，就自动批准并合并。
4. 如果改动涉及配置文件、工作流或代码文件，则不会合并，等待人工审核。

这种做法的好处是兼顾自动化和安全。参与者可以自由编辑 content 目录下的页面，但无法动工作流配置。

4.2 方式二：分支保护规则 + GitHub 内置自动合并

如果不想写复杂的工作流，也可以在仓库设置中启用 GitHub 的原生功能：

1. 在Settings -> Branches -> Add rule给main分支添加保护规则。
2. 勾选“Require a pull request before merging”，但不设置人工审批数量。
3. 开启“Allow auto-merge”选项。
4. 配置一个自动化机器人（比如 Dependabot 专用流程）或在 Actions 中通过gh pr merge --auto开启自动合并。

实际使用中，需要先让某个机器人或脚本对 PR 调用一次gh pr merge --auto，GitHub 会自动在 CI 通过后立即合并。

对于项目里的“任何人可编辑”特性，更推荐方式一，因为可以在合并前做文件路径和内容校验。

4.3 第三方自动合并机器人

如果你不想自己维护 Actions，也可以直接用开源社区成熟的自动合并机器人，比如：

• Mergify：提供非常灵活的 PR 自动合并规则，支持按文件路径、作者、标签、分支名等条件判断。
• Renovate Bot+Auto Merge配置：主要面向依赖更新场景。
• Kodiak：一个独立的 PR 管理机器人，支持自动更新、自动合并、退出旧 branch。

使用 Mergify 的配置示例如下：

pull_request_rules: - name: auto merge content changes conditions: - files~=^content/ - check-success=build - "#changes-requested-reviews-by=0" actions: merge: method: squash

5. 内容编辑与 PR 提交流程模拟

要让“任何人可编辑”真正落地，编辑流程必须足够简单。下面模拟一次完整的编辑提交流程。

5.1 场景示例

假设网站有一个“活动公告”页面，内容在content/pages/events.md。访客发现活动时间写错了，希望修改。

参与者的本地操作流程：

# Fork 仓库后，在本地克隆 git clone git@github.com:yourname/contribute-site.git cd contribute-site # 创建新分支 git checkout -b fix-events-date # 编辑内容文件 vim content/pages/events.md # 提交变更 git add content/pages/events.md git commit -m "fix: correct event start time to 14:00" # 推送分支 git push origin fix-events-date

推送完成后，打开 GitHub 页面点击“Compare & pull request”发起 PR。PR 标题和描述会自动带上提交信息。

此时项目配置的 auto-merge 工作流会:

1. 检测到从fix-events-date分支发起了一个 PR。
2. 检查变更文件是否都在content/目录中。
3. 验证通过后自动批准 PR。
4. 执行自动合并。
5. 合并后触发部署工作流，将内容构建并发布。

整个过程不需要任何人手动点合并按钮。从 PR 提交到内容上线，通常在 1 到 5 分钟内完成，具体取决于 CI 耗时。

5.2 使用 GitHub CLI 直接提交 PR

对于高级用户，可以直接用 GitHub CLI 完成提交流程，连网页都不用打开：

# 创建 PR gh pr create \ --base main \ --head fix-events-date \ --title "fix: correct event start time to 14:00" \ --body "Update event page with correct time" # 查看 PR 是否被自动合并 gh pr status

6. 自动合并触发后的发布链路

自动合并只是第一步，真正的网站更新还需要在合并事件后触发部署。

部署工作流示例，放在.github/workflows/deploy-site.yml：

name: Deploy Website on: push: # 只在 main 分支变化时触发 branches: [main] paths: - 'content/**' - 'src/**' - 'package.json' - 'yarn.lock' jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '20' - name: Install dependencies run: | npm install || yarn install - name: Build static site run: | npm run build || yarn build - name: Deploy to server run: | # 示例：通过 rsync 推送静态文件到服务器 # 需要提前配置 SSH 私钥和已知主机信息 # 也可以使用第三方 Action 部署到 Netlify/Vercel/Cloudflare Pages rsync -avz --delete dist/ user@your-server:/var/www/html/

路径过滤条件paths可以避免一些无关改动触发部署，例如 README 变更。

如果需要防止构建失败导致站点下线，建议在部署前增加构建产物预览，例如输出一个带 commit id 的版本文件：

echo "${{ github.sha }}" > dist/VERSION.txt

7. 接口 API 与 GitHub 集成扩展

“任何人可编辑”除了通过网页手动提交 PR，还可以走 GitHub REST API 实现自动提交和批量任务。

GitHub API 允许第三方程序在用户授权后创建分支、提交文件、发起 PR。对于需要定期更新内容的场景，可以直接用脚本自动打开 PR。

一个简单的 Python 示例，自动创建一个修改文件的新 PR：

import os import requests GITHUB_TOKEN = os.environ["GITHUB_TOKEN"] REPO_OWNER = "your-name" REPO_NAME = "website-content" MAIN_BRANCH = "main" BASE_URL = "https://api.github.com" headers = { "Authorization": f"token {GITHUB_TOKEN}", "Accept": "application/vnd.github+json", } # 1. 从主分支创建新分支 branch_name = "auto-update-event" url = f"{BASE_URL}/repos/{REPO_OWNER}/{REPO_NAME}/git/refs/main" r = requests.get(url, headers=headers) sha = r.json()["object"]["sha"] url = f"{BASE_URL}/repos/{REPO_OWNER}/{REPO_NAME}/git/refs" payload = { "ref": f"refs/heads/{branch_name}", "sha": sha, } requests.post(url, headers=headers, json=payload) # 2. 提交文件修改（此处需要先获取文件 blob、创建新 blob、再提交 tree） # 简化步骤：直接通过 API 读取文件内容，更新后创建 commit # 3. 创建 PR url = f"{BASE_URL}/repos/{REPO_OWNER}/{REPO_NAME}/pulls" payload = { "title": "docs: auto update event list", "head": branch_name, "base": MAIN_BRANCH, "body": "Automated batch update from scheduling script.", } r = requests.post(url, headers=headers, json=payload) print(f"PR created: {r.json()['html_url']}")

利用这个 API 链路，可以让外部系统（例如爬虫、定时脚本、消息队列）自动生成 PR 并提交到仓库，再由自动合并机制快速上线。

8. 批量任务与多 PR 并发处理

如果要在短时间内批量更新站点内容，需要注意几个问题。

8.1 多 PR 自动合并的竞态

当多个 PR 同时被自动合并时，如果在创建 PR 时没有同步最新 main 分支，后合并的 PR 在合并时可能会失败或产生冲突。GitHub 的自动合并在检测到冲突时会等待，手动解决后才会继续。

减少冲突的方法：

• 每次 PR 尽量只改少量文件。
• 让参与者先 rebase main 分支再推送新提交。
• 自动合并前对 PR 执行自动 rebase（Mergify 和 Kodiak 支持）。
• 内容文件按页面拆分成单独文件，降低同时修改同一文件的可能性。

8.2 大批量内容更新的目录设计

如果要批量更新 100 个页面，不要在一个 PR 里塞 100 个文件变更。一方面难以 review，另一方面冲突概率高。更合理的方案是拆成多个 PR，每个 PR 负责一类内容。

可以用脚本按目录批量生成 PR：

for dir in pages/posts pages/events pages/docs; do branch_name="update-$(basename $dir)" git checkout -b "$branch_name" origin/main # 对 $dir 目录下的文件做批量修改 git add "$dir" git commit -m "batch update $dir" git push origin "$branch_name" gh pr create --base main --head "$branch_name" --title "batch update $dir" --body "auto generated" sleep 10 done

由于自动合并工作流会处理每个 PR，这个循环完成后网站内容会分批上线。期间如果某个 PR 因为文件路径不合法被拦截，也只影响那一批。

9. 资源占用与执行效率观察

这个项目的核心运行环境是 GitHub Actions，不是本地服务。所以资源占用主要指 GitHub Actions 的执行时间、并发额度和仓库体积。

需要注意以下几点：

1. Actions 执行时间：自动合并工作流和部署工作流每次运行都会消耗 GitHub Actions 的免费额度。对于小型项目，每月 2000 分钟基本够用。
2. 并发数限制：免费账号同时最多 20 个 job。如果 PR 数量很大，工作流会排队等待。
3. 仓库体积：如果用户提交大量图片、二进制文件，仓库体积会膨胀。建议在 content 中尽量使用文本文件，图片走外部图床或 LFS。
4. 构建时间：使用纯静态站点生成器（如 VitePress、Astro）比使用 Next.js 服务端渲染更快，也更省钱。
5. 本地预览资源：本地启动开发和预览服务时，Node 进程的内存占用通常在 500MB 到 1GB 之间，根据项目规模而定。

观察执行效率的方法很简单，在 GitHub 仓库的 Actions 页面查看每次运行的时间线即可。如果发现部署工作流经常超过 5 分钟，优先检查依赖安装和构建步骤。

10. 常见问题与排查方法

最常见的坑是自动合并工作流使用了无权限的 token。注意permissions: contents: write是必须的，否则gh pr merge会返回 403。

另一个常被忽略的问题是：如果自动合并工作流被修改（.github/workflows/auto-merge.yml本身被改动），会触发工作流运行吗？不会。默认情况下，从 fork 仓库发起的 PR 拿到的工作流文件中定义的 secrets 是不透传的，这符合安全预期。但从主仓库直接创建的 PR 修改工作流文件是危险的，建议通过路径限制阻止非授权修改。

11. 最佳实践与使用建议

基于这个项目的模式，下面是一套经过验证的工程化建议。

11.1 第一次先小范围测试

不要一上来就开放整个仓库的自动合并。先只开放content/下的一个子目录，用一个小范围 PR 验证整个流程可以跑通，再逐步扩大。

11.2 强制要求 PR 描述格式

参与的编辑者越多，PR 描述越混乱。建议在自动合并工作流中检查 PR 标题和 body 是否存在，不符合规则的 PR 打上needs-format标签并自动关闭。

- name: Validate PR format if: steps.changed_files.outputs.contains_non_content_files == 'false' run: | PR_TITLE="${{ github.event.pull_request.title }}" if [[ "$PR_TITLE" == *"[[NO_EDIT]]"* ]]; then echo "PR title cannot contain edit block marker" exit 1 fi

更稳妥的做法是利用 GitHub 的“CODEOWNERS”机制，让内容目录指定一个负责人。当 PR 修改 content 目录时，自动分配到该负责人名下，只有负责人 approve 后才自动合并。这样既保留自动化的效率，也有一个人工兜底环节。

11.3 使用 squash merge 保持历史整洁

强烈建议自动合并使用 squash merge，把 PR 的所有提交合并为一个提交，这样git log可读性很高，回滚时候只需要 revert 一个 commit。

11.4 保留一套最小可运行配置

即使仓库没有部署上线，也建议把自动合并工作流保留在一个独立仓库里。后续需要做一个新的可编辑网站时，直接复制仓库模板即可。

11.5 内容更新要有审计和通知

每次自动合并后，可以让部署工作流推送一条消息到 Slack 或飞书群，内容包含 PR 链接、变更文件列表和合并人。这样团队可以第一时间知道网站发生了什么变化。

- name: Send notification run: | VERSION=$(cat dist/VERSION.txt) curl -X POST "$NOTIFY_WEBHOOK_URL" \ -H "Content-Type: application/json" \ -d "{\"text\":\"Website updated to $VERSION\"}" if: success()

11.6 合规与授权提醒

如果这个机制开放给公众参与编辑，网站可能会面临内容合规和版权风险。需要特别留意：

1. 参与者提交的图片、文字必须确认拥有版权或已获得授权。
2. 涉及人物肖像、商标、个人信息的内容，要严格按照平台规则处理。
3. 自动合并不等于自动发布免责，作为站点管理员仍然要对线上内容负责。
4. 如果未来出现争议内容，快速回滚并保留证据。

12. 总结与下一步

这个项目的核心思路非常有价值：把“编辑权限”和“部署能力”解耦。参与编辑的人不直接操作服务器，而是通过 Git 和 PR 走标准化的提交、审核、合并流程。GitHub Actions 只是把合并和部署这两个环节自动化掉了。

最值得尝试的点是它的“自动合并 PR”工作流，它不仅适用于网站，也可以用在任何需要多人协作维护的文件库上。建议第一件事就是在本地仓库创建一个content/目录，配好路径过滤和自动合并，提交一个测试 PR。

最容易踩的坑有两个：一是 GitHub Actions 权限没配好，合并时报 403；二是自动合并范围太宽，导致核心配置被意外修改。

后续可以扩展的方向包括：接入 CI 内容格式校验（检查 Markdown 语法、图片压缩、链接有效性）、增加基于作者身份的自动合并白名单、把部分管理功能做成一个 Web 控制台，通过 GitHub API 把 PR 列表和合并状态可视化展示出来。

如果你已经在用 GitHub 作为内容仓库，这个思路可以直接套用，不需要引入额外系统。值得收藏备用。