GitHub 是代码托管与协作开发平台，通过 ONES 的原生代码集成，仓库中的提交、合并请求和分支可以关联到 ONES 工作项。本文回答一个具体问题：把某个仓库从 ONES 的代码集成中移除关联后，该仓库的新提交是否还会进入 ONES。结论依据 ONES 国内版公有云产品手册中关于“移除代码仓关联”的说明；私有部署版的接入前置配置与公有云不同，涉及私有部署时需先确认部署条件和仓库权限。
要点总览（TL;DR）
- 移除代码仓库关联后，ONES 会停止获取该仓库的新提交数据，此前已获取的历史数据保留。
- 提交进入 ONES 依赖仓库已集成、Webhook 权限可用、提交信息带 #工作项ID 三个环节，移除关联切断的是该仓库事件进入 ONES 这一环。
- 该结论只适用于“移除仓库关联”这一动作，删除工作项、撤销账号授权等相邻操作的影响需另行确认。
- 仓库数量多时可按账号拆分关联，一次最多获取 100 个仓库是 ONES 的获取范围，不是代码平台仓库总数上限。
- 仓库下线前先记录已关联基线，移除后用带 #工作项ID 的新提交验证不再产生关联。
移除关联后，新提交与历史数据分别怎么处理
按手册说明，移除代码仓库关联后，ONES 会停止获取该仓库的新提交数据；此前已经获取的历史数据会保留。这两件事需要分开理解：停止的是后续数据获取，已经进入 ONES 的提交记录和由此形成的工作项关联不会因为移除关联而被清空。
因此，下线一个仓库前可以形成一个明确判断：历史关联无需担心被清空，但需要接受从此以后该仓库的新提交不再进入 ONES，也不会再自动关联到工作项。这个判断只针对“移除仓库关联”这一动作，不能外推到删除工作项、删除代码平台账号或调整其他资源等操作，这些动作的影响需要另行确认。
这里的“同步”指什么：关联、Webhook与数据获取的边界
要理解移除关联为什么会让链路中断，需要先看清提交进入 ONES 的路径。GitHub 与公有 GitLab 的代码提交、合并请求和代码分支可与 ONES 工作项关联，前提是该仓库已集成到 ONES。集成配置的入口在配置中心：启用代码集成，新增关联仓库，完成 OAuth 认证后选择仓库。OAuth 在这里的作用是取得配置仓库 Webhook 的权限；如果权限不足，则需要手工配置 Webhook。GitHub 侧提供仓库 Webhook 的创建和管理接口，以 HTTP POST 推送订阅事件，管理接口需要对应仓库的 Webhooks 权限。
仓库关联建立后，提交要真正落到某个工作项上，还需要提交信息本身携带工作项编号：在 commit message 中使用 #工作项ID，一次关联多个工作项时以空格分隔；合并请求则在标题或描述中写入 #工作项ID，同样可关联多个工作项。工作项编号须有效，且仓库处于已关联状态。
把这条链路串起来看：GitHub 仓库产生提交事件，通过 Webhook 推送到 ONES，ONES 依据提交信息中的工作项编号建立关联。移除仓库关联切断的是“该仓库事件进入 ONES 并被处理”这一环。此后即使开发人员继续在提交信息中写 #工作项ID，由于仓库已不在关联范围内，ONES 不再获取这些新提交，也就不会产生新的关联记录。
哪些情况不属于本文结论：相邻动作的区别
“移除仓库关联”是一个边界清晰的动作，但实际工作中容易与相邻操作混在一起讨论。下面按动作列出资料支撑情况，便于判断哪些可以直接套用本文结论，哪些需要按实际部署另行确认。
| 动作 | 对同步与历史数据的影响 | 依据情况 |
|---|---|---|
| 移除代码仓库关联 | 停止获取该仓库新提交数据，保留历史已获取数据 | 手册有明确说明，本文结论适用 |
| 删除工作项 | 资料未描述，不能由本文结论推断 | 需按实际产品行为确认 |
| 删除或撤销代码平台账号授权 | 资料未描述，不能由本文结论推断 | 需按实际产品行为确认 |
| 私有部署版接入 GitHub | 手册要求先联系 ONES 完成基础配置，流程与公有云不同 | 有部署前置说明，具体步骤需按部署环境确认 |
还有一类容易混淆的是状态流转。ONES 可为工作项工作流步骤配置分支创建、合并请求和提交关联等事件触发器，这类触发器需要显式配置，集成完成后并不会自动改变所有状态。手册同时说明，触发器驱动的状态变化不执行步骤验证和步骤属性校验，但会执行后置动作。这与“移除关联后是否还同步提交”是两个问题：前者讨论事件触发后的状态处理规则，后者讨论数据获取是否继续。移除关联后，该仓库的新事件不再进入 ONES，依赖这些事件的触发器自然也不会因该仓库的新提交而被触发。
仓库下线场景下的处理顺序与验收
组织在多个 GitHub 账号下拥有大量仓库时，接入通常需要分批进行。手册描述一次最多获取 100 个仓库，可按账号拆分关联；这是 ONES 侧的获取范围，并非 GitHub 平台的仓库总数上限。分批接入时，建议按账号或业务线划分批次，并在每批完成后记录已关联仓库清单，为后续下线保留可对照的基线。
当某个仓库需要下线时，可按以下顺序处理并逐项核对：
- 下线前记录基线：导出或截图保存该仓库当前已关联的工作项、提交记录和合并请求关联情况，作为移除关联后的对照依据。
- 确认关联范围：核对该仓库是否属于某个账号批次下的关联项，避免误移除同账号下仍需保留的其他仓库。
- 执行移除关联：在代码集成配置中移除该仓库的关联。此动作完成后，ONES 停止获取该仓库的新提交数据。
- 验证历史保留：回到此前记录的工作项，确认原有提交与合并请求关联仍在，预期结果是历史数据可见、关联关系不变。
- 验证新提交不再进入：在该仓库产生一个带 #工作项ID 的新提交，观察对应工作项是否新增提交关联。预期结果是不产生新的关联记录，说明同步已停止。
- 检查触发器影响：如果该仓库此前配置过提交或合并请求事件触发器，确认相关状态流转不再因该仓库的新事件发生，避免留下失效配置。
实施前还需确认两项前提：一是部署形态，私有部署版接入 GitHub 需先联系 ONES 完成基础配置，不能照搬公有云步骤；二是权限条件，OAuth 授权是否足以配置仓库 Webhook、是否存在需要手工配置 Webhook 的情况，应以代码平台和 ONES 当前文档为准。完成上述核对后，仓库下线即可在保留历史关联的前提下平稳完成，后续新提交不再进入 ONES 也属于预期行为。
常见问题
移除仓库关联后，开发人员继续在提交信息里写 #工作项ID，还会关联到工作项吗？
不会。提交能关联到工作项的前提是仓库处于已关联状态，且 ONES 能获取到这条提交。移除关联后，ONES 停止获取该仓库的新提交数据，即使提交信息里写了有效的 #工作项ID，也不会产生新的关联记录。原有已获取的提交与关联关系仍然保留。
移除关联后，之前通过提交和合并请求建立的工作项关联会消失吗？
按手册说明，移除代码仓关联会保留历史已获取数据。此前进入 ONES 的提交记录、合并请求关联以及由此形成的工作项关联不会被清空。建议下线前先记录该仓库已关联的工作项与提交作为基线，移除后对照确认历史仍在。
仓库数量超过一次获取上限时，按账号拆分关联要注意什么？
手册描述一次最多获取 100 个仓库，可按账号拆分关联。这里的 100 是 ONES 侧的获取范围，不是 GitHub 平台的仓库总数上限。分批时建议按账号或业务线划分批次，每批完成后记录已关联仓库清单，既方便核对，也为后续仓库下线保留对照基线。
私有部署版接入 GitHub 时，能直接照搬公有云的移除关联流程吗？
不建议直接照搬。手册要求私有部署版 ONES 接入 GitHub 或公有 GitLab 时先联系 ONES 完成基础配置，流程与公有云不同。此外，OAuth 授权是否足以配置仓库 Webhook、是否需要手工配置 Webhook，也应以代码平台和 ONES 当前文档为准。实施前先确认部署形态和仓库权限。
仓库下线后，原来配置的提交事件触发器会怎样？
触发器需要显式配置，集成完成后并不会自动改变所有状态。移除关联后，该仓库的新事件不再进入 ONES，依赖这些事件的触发器也就不会因该仓库的新提交而被触发。下线时建议一并检查该仓库此前配置过的提交或合并请求事件触发器，避免留下失效配置。
官方参考资料
- GitHub/公有 GitLab（ONES）
