probot 不能自动 merge，真正能实现的是 github actions（如 devmasx/merge-branch）；probot 是开发框架，无 git 操作能力，且默认无写权限、无法执行 shell 命令、响应延迟高。
Probot 本身不提供自动 Merge 功能，别被名字误导
Probot 是一个 GitHub App 开发框架，不是开箱即用的“自动合并工具”。你搜到的 Merge Branch Action 或 devmasx/merge-branch 是独立的 GitHub Actions，和 Probot 没有代码或架构依赖关系。混淆常发生在文档里写“基于 Probot 生态”，其实只是指“同属 GitHub 自动化工具家族”，并非技术集成。
如果你在项目里看到 probot 相关依赖却想实现自动合入，大概率是误配了——它不会监听 PR 合并事件，也不具备 Git 操作能力（如 git merge、git push），这些必须由 Actions runner 或外部服务执行。
真正能自动 Merge 的是 GitHub Actions：devmasx/merge-branch
这个 Action 是目前最轻量、配置最直接的分支自动合入方案，适用于定时同步、标签触发、PR 合并后联动等场景。它不依赖 Probot，纯靠 GitHub Actions 工作流驱动。
-
type支持now（立即）和cron（定时），比如每天凌晨同步main到stable -
from_branch和target_branch必填，顺序反了会覆盖错误分支 -
github_token必须用${{ secrets.GITHUB_TOKEN }}，不能用个人 token（权限不足） - 若配合
label_name: ready-to-merge，需确保 PR 创建者或协作者有打标签权限，否则 workflow 不触发
示例片段（.github/workflows/merge.yml）：
on:
pull_request:
types: [labeled, unlabeled]
branches: [main]
jobs:
auto-merge:
runs-on: ubuntu-latest
steps:
- uses: devmasx/merge-branch@v3
with:
type: now
from_branch: main
target_branch: production
github_token: ${{ secrets.GITHUB_TOKEN }}
message: "chore: auto-merge main → production"
为什么不用 Probot 做自动 Merge？三个硬伤
即使你强行用 Probot 实现类似逻辑，也会踩进以下坑里：
- Probot 默认无写权限：要手动在 GitHub App 设置中勾选
Contents: Read and write，否则octokit.repos.merge()直接报403 Resource not accessible by integration - 无法原生执行 shell 命令：像
git checkout、git push这类操作得调 GitHub REST API 模拟，代码复杂度飙升 - 事件响应延迟高：Probot 处理
pull_request.labeled通常比 Actions 慢 2–5 秒，对时效性要求高的合入（如 CI 通过后秒级合入）不可靠
更现实的做法是：用 Actions 做 Merge，用 Probot 做配套动作（比如合入后自动发 Slack 通知、更新 issue 状态）。两者分工明确，而不是硬塞进一个框架。
如果真要用 Probot 触发 Merge，只推荐一种安全模式
仅当你的团队已有一套成熟的 Probot 插件体系，且所有仓库都统一部署了该 App，才考虑用它做“条件判断 + 调用 Actions”桥接。核心思路是：Probot 监听事件 → 验证业务规则（如 label、author、CI status）→ 调用 GitHub REST API 手动触发预定义的 Actions workflow。
- 必须提前在目标仓库启用
workflow_dispatchevent，并配置inputs参数接收 branch 名 - Probot 中调用
octokit.request('POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches', ...) - 不能直接传
github_token给 Probot，要用 App 安装时生成的installation access token，有效期仅 1 小时，需每次刷新
这种链路增加了单点故障风险，调试成本远高于直接写 Actions。除非你已有 Probot 运维团队，否则不建议走这条路。
真正容易被忽略的是权限粒度——GitHub 对 merge 操作的限制比想象中细：即使 App 有 Contents: write，也默认禁止向 protected branch 合并，必须额外关闭 branch protection 的 Require pull request reviews before merging 或配置 bypass rules。这点在测试环境常被绕过，上线后突然失败。
