先别迁库：Cursor Origin同步GitHub时，权威源仍在GitHub

要把 GitHub 仓库接入仍处早期 Beta 的 Cursor Origin，可在 Codebase 页面选择“Sync from GitHub”，连接 GitHub、选择组织和目标仓库，再确认同步。Origin 会保存持续更新的镜像，但对这种同步仓库的推送会转交 GitHub，GitHub 仍是权威源。

因此，这更适合作为单仓库试用，而不是迁库：先选一个非关键仓库，验证授权范围、推送去向、PR 双向同步和现有 CI，再决定是否扩大。试用期间不必把 GitHub Actions、密钥、分支保护或发布流程搬到 Origin。

先划清边界：镜像同步不改变权威源

Cursor 的 GitHub 镜像文档 列出了当前边界：同步需要具备 Origin 访问权限、连接拥有目标仓库的 Cursor GitHub App，并拥有该 GitHub 仓库的管理员权限；同步内容包括 Git 历史、分支、标签、可浏览和搜索的代码，以及双向同步的 PR，但不包括 GitHub Issues、Actions 工作流和密钥。

同步完成后，可在仓库的 Settings → General 中确认 Origin 是镜像、GitHub 是源。即使从 Origin 远端克隆并推送，写入也会传递到 GitHub；只有执行“Detach from GitHub”后，Origin 副本才转成独立托管仓库并成为权威源，而原 GitHub 仓库不受影响。

这正是“先别迁库”的事实基础：连接、断开和推送行为会改变两端的角色，不能仅凭代码已经出现在 Origin 就认定托管完成迁移。低风险试用应始终保留 GitHub 作为最终提交、合并与发布状态的核验位置。

只接入一个非关键仓库，并核对权限

试点仓库应能覆盖真实协作链路，又不能在同步异常时影响关键发布。内部工具、示例项目或易于回滚的服务较合适；仓库最好已有开放 PR、自动检查和接近正式项目的权限结构，否则只能验证代码是否可见，无法检验团队真正依赖的流程。

1. 打开 cursor.com/codebase，选择“Sync from GitHub”。
2. 连接拥有目标仓库的 GitHub 组织或账户，并确认 Cursor GitHub App 只获得必要范围。
3. 选择预定的非关键仓库并确认同步，不进行全组织批量接入。
4. 同步完成后，核对默认分支、近期提交、标签和开放中的 PR。
5. 在 Settings → General 检查同步状态，并复核仓库权限和已连接应用。

权限验证应覆盖至少两种角色：管理员或维护者确认审查、推送和合并路径，只读成员确认可见内容没有超出 GitHub 原授权。若仓库未出现在列表中，应先检查 GitHub App 的安装范围、仓库管理员权限和组织策略，不要通过新建同名 Origin 仓库绕过授权问题。

用一次无业务影响的提交确认推送去向

同步成功后，可从 Origin 副本克隆仓库，创建一个明确标注为试验用途的短期分支，并提交一处无业务影响的文档修改。随后执行 git remote -v，记录抓取和推送地址，再从该分支发起 PR。

验收重点不只是远端名称，而是写入结果：测试提交应出现在 GitHub，Origin 随后反映同一提交；两端显示的提交 SHA 应一致。Origin 能浏览某个提交，只能证明镜像已更新，不能单独证明主写入路径已经迁移。

再断开本地网络缓存或重新克隆 GitHub 仓库，确认该分支和提交仍可从 GitHub 获取。这个步骤不是破坏性故障演练，而是用独立读取确认 GitHub 保存了团队后续工作所需的完整记录。

PR 会双向同步，CI 不会随镜像自动搬过去

Cursor 在 2026 年 8 月 17 日的 Origin 更新说明 中将其状态标为向付费方案逐步推出的早期 Beta，并说明同步仓库的 PR 评论、回复和表情回应可在 Cursor 与 GitHub 之间双向同步；页面也列出 Vercel、Depot 和 Buildkite 集成，其中 Depot 与 Buildkite 可运行已有的 GitHub Actions 工作流，但需要在仓库的 Apps 区域单独连接。

代码和 PR 同步不代表 CI 配置已经迁移。镜像文档明确排除了 GitHub Actions 工作流与密钥，因此第一阶段应保留现有 Actions、Webhook、环境变量和分支保护，只验证 Origin 能否正确反映检查结果。若要试用 Origin 的应用集成，应把安装权限、凭据和回调结果作为独立测试项。

• 从 Cursor 评论测试 PR，在 GitHub 核对内容与身份。
• 从 GitHub 回复或添加回应，在 Cursor 核对同步结果。
• 推送第二个提交，确认两端显示相同的最新 SHA。
• 让一个测试检查保持失败，确认保护规则仍阻止合并。
• 若连接 CI 应用，单独验证安装范围、密钥来源和运行结果。

合并判断仍应以 GitHub 的保护规则为准。GitHub 的必需状态检查说明 指出，必需检查必须针对最新提交 SHA 通过；被路径、分支或提交信息过滤而跳过的工作流可能保持 Pending 并阻止合并，使用合并队列的 Actions 工作流还需要响应 merge_group 事件。

提前写明继续试用与退出条件

至少完成一个完整 PR 周期后再评估，包括建分支、推送、评论、回复、检查、审查、合并和删除分支。只完成初始同步，无法证明 Origin 能稳定承载日常协作。

出现无法解释的同步滞后、两端提交或审查状态不一致、必需检查未对应最新 SHA、成员可见性超出预期，或现有 CI 必须大幅改造才能维持原有保护效果时，应暂停扩大范围。退出镜像试用时，先停止从 Origin 发起新操作，再核对 GitHub 的默认分支、开放 PR、应用授权、Webhook 和最近一次成功流水线；不要选择 Detach，除非团队确实准备让 Origin 副本转为独立权威仓库。

继续试用的条件同样应可观察：GitHub 始终保存最终提交与合并状态，Origin 稳定反映仓库和 PR 变化，授权范围没有意外扩大，CI 与分支保护也未被削弱。满足这些条件后，可以逐仓库增加范围；一次成功的镜像验证仍不等于完成托管迁移。