GitHub 是代码托管与协作开发平台，通过 ONES 的原生代码集成，仓库中的提交、合并请求和分支可以关联到 ONES 工作项。本文回答解除仓库关联后这些关联记录是否还在，口径为 ONES 国内版公有云产品手册；私有部署版接入 GitHub 需先联系 ONES 完成基础配置，具体版本与仓库权限仍以实际部署环境核验为准。
要点总览（TL;DR）
- 会保留：按 ONES 国内版公有云产品手册，移除代码仓关联后停止获取该仓库的新提交数据，此前已获取的历史数据继续保留。
- 保留的是 ONES 侧已接收的提交、合并请求、分支与工作项的关联记录，GitHub 仓库里的代码本体不受影响。
- 结论只覆盖“移除仓库关联”这一动作，不外推到删除工作项、删除项目或 GitHub 侧删除仓库。
- 前提是仓库此前已完成集成，接入需要代码集成配置权限与仓库 Webhook；私有部署需先联系 ONES 完成基础配置。
- 多账号仓库可按账号分批关联，手册描述一次最多获取 100 个仓库，这是 ONES 的获取范围，不是 GitHub 平台上限。
直接答案：解除关联后历史保留、新提交停止同步
会保留。按 ONES 国内版公有云产品手册的描述，移除代码仓关联后，系统停止获取该仓库的新提交数据，此前已获取的历史数据继续保留。也就是说，解除关联前已经形成的提交与工作项关联记录，不会因为这次操作被清空。
这条结论有三条前提边界，超出范围的情况需要另行确认：
- 仓库此前已经完成集成并关联到 ONES，从未接入过的仓库不存在“历史数据”可谈。
- 操作对象是“移除仓库关联”这一动作本身，手册的描述只覆盖这一动作。
- 结论不外推到删除工作项、删除项目等其他资源操作，这些动作的数据影响属于另一类问题。
另外，上述口径来自国内版公有云产品手册。使用私有部署版 ONES 接入 GitHub 时，手册要求先联系 ONES 完成基础配置，配置完成后的行为以对应部署环境的文档为准。
“提交关联历史”在 ONES 里指什么
这里被保留的对象，是 ONES 侧已经接收并记录的关联数据，而不是 GitHub 仓库里的代码。理解这一点，才能准确判断解除关联会影响什么、不影响什么。
按手册描述，GitHub 的代码提交、合并请求和代码分支都可以与 ONES 工作项建立关联。关联的形成依赖提交信息中的约定写法：在 commit message 中写入 #工作项ID，一次关联多个工作项时以空格分隔；在合并请求的标题或描述中写入 #工作项ID，同样可以关联多个工作项。这些写法生效的前提是工作项编号有效、源仓库已完成 ONES 集成。
因此，“提交关联历史”在 ONES 里表现为工作项上可见的提交、合并请求、分支等关联条目，以及这些条目携带的提交信息。它不包括以下内容：
- GitHub 仓库中的源代码本体，代码始终存放在 GitHub 侧，不因关联或解除关联而移动。
- 工作项自身的状态、字段和流转记录，解除仓库关联不会让工作项回滚到某个早期状态。
- 由触发器驱动的历史状态变化结果，这些是已经发生的工作项变更，与关联记录是否保留是两个问题。
解除关联时系统做了什么：数据流与停止点
“保留历史”与“停止同步”能同时成立，原因在于集成依赖事件推送，而解除关联切断的是后续事件的获取路径，不是已入库的记录。
接入环节的动作顺序是：在配置中心启用代码集成，新增关联仓库，完成 OAuth 认证后选择仓库。OAuth 的作用是取得配置仓库 Webhook 的权限；如果权限不足，需要手工配置 Webhook。GitHub 侧提供仓库 Webhook 的创建和管理接口，以 HTTP POST 向订阅方推送事件，管理接口需要对应仓库的 Webhooks 权限。事件推送构成数据进入 ONES 的通道。
把这条链路拆开看，停止点很清楚：
- 解除关联之前：GitHub 仓库产生提交、合并请求等事件，经 Webhook 推送进入 ONES，按
#工作项ID规则形成关联记录。 - 解除关联之后：该仓库后续事件不再被获取，新的提交不会出现在 ONES 的关联条目中。
- 已入库的历史记录：作为 ONES 侧已有数据保留，不因事件源被切断而删除。
需要留意的是，触发器配置与关联记录是两件事。手册说明可以为工作项工作流步骤配置分支创建、合并请求和提交关联等事件触发器，这类触发器需要显式配置，集成完成后并不会自动改变所有状态。触发器驱动的状态变化不执行步骤验证和步骤属性校验，但会执行后置动作。解除关联后，该仓库不再产生新事件，依赖这些事件触发的状态变化自然也不再发生，但此前已经发生的状态变化结果仍然留在工作项上。
容易混淆的相邻概念：解除关联、停止同步与删除数据
实际操作中，几个动作常被混用，按错误预期操作容易造成误判。下表按“对 ONES 中已有数据的影响”这一口径对照三类动作。
| 动作 | 对后续数据的影响 | 对已有历史的影响 | 说明 |
|---|---|---|---|
| 在 ONES 移除仓库关联 | 停止获取该仓库的新提交数据 | 保留历史已获取数据 | 手册明确描述的动作，本文结论仅覆盖此项 |
| 删除工作项或删除项目 | 属于另一类资源操作 | 手册未将其与解除关联等同 | 不能套用“保留历史”的结论，需按对应规则确认 |
| 在 GitHub 侧删除仓库 | 影响 GitHub 平台上的代码与事件源 | 与 ONES 侧移除关联是两件事 | GitHub 平台的仓库删除、归档与数据保留策略不在本文范围 |
还有一组容易混的点：解除关联停止的是“新数据获取”，触发器停止的是“新事件引发的状态变化”，两者都源于事件通道被切断，但前者讨论关联记录，后者讨论工作项状态。判断某个操作会不会影响历史时，先确认它改变的是事件通道、关联记录，还是工作项本身。
一个具体例子：仓库下线前后的预期结果
假设某仓库已关联到 ONES，开发过程中产生了若干条在 commit message 中写入 #工作项ID 的提交，对应工作项上已经能看到这些提交关联。现在该仓库准备下线，团队在 ONES 中移除它的关联。
解除后可以观察到的结果：
- 打开此前被关联的工作项，仍能看到解除之前形成的提交关联条目，这些记录没有被清空。
- 该仓库在解除之后产生的新提交，不再出现在 ONES 的关联条目中。
- 工作项当前的状态和字段值保持解除时的样子，不因解除关联而回滚。
如果后续需要重新关联同一仓库，历史记录与新增数据如何衔接，需按当前版本的文档确认，本文不对此作推断。稳妥的做法是在解除前把该仓库的关联情况核对清楚，而不是依赖重新关联来补回数据。
多账号大量仓库的接入批次与解除顺序
组织在多个 GitHub 账号下拥有大量仓库时，接入和下线都需要按批次规划。手册描述一次最多获取 100 个仓库，可按账号拆分关联。这里的 100 是 ONES 的获取范围，不是 GitHub 平台的仓库总上限，规划时不要把它理解为账号侧的容量限制。
接入阶段可以按账号划分批次，每个账号作为一批完成关联，并记录该批覆盖的仓库清单。这样做的直接好处是：后续某个仓库下线时，能快速定位它属于哪一批、关联了哪些工作项。
解除关联前的核对清单：
- 确认该仓库的关联记录已满足留档需要，包括需要长期追溯的提交与合并请求条目。
- 确认该仓库不再有依赖其事件触发的工作项状态流转需求，解除后新事件不再进入 ONES。
- 确认操作对象是移除仓库关联，而不是删除工作项或项目。
- 确认执行人具备代码集成配置权限；权限不足时，Webhook 需要手工配置，接入阶段就应把这一前置条件处理掉。
- 私有部署环境先确认已完成 ONES 侧的基础配置，且接入流程按 GitHub 或公有 GitLab 的路径执行，不与私有 GitLab 的接入流程混用。
按批次接入、按清单核对、按仓库逐个解除，能让“停止同步、保留历史”这条规则在实际下线操作中稳定落地：下线仓库不再产生新数据，已形成的关联记录继续留在对应工作项上，供后续追溯使用。
常见问题
解除关联后，工作项上原来显示的提交记录会立刻消失吗？
不会。按手册描述，移除代码仓关联停止的是该仓库新提交数据的获取，此前已获取的历史数据继续保留。因此解除之前已经形成的提交、合并请求、分支关联条目仍留在对应工作项上，可供追溯。
需要区分的是，解除之后该仓库产生的新提交不再进入 ONES，工作项上不会新增来自这个仓库的关联条目。
如果只是暂停使用某个仓库，过一段时间再重新关联，历史会怎样？
解除关联期间，该仓库的新提交不会被获取，这段时间的提交不会自动补入 ONES。重新关联后历史记录与新增数据如何衔接，需按当前版本的文档确认，本文不作推断。
更稳妥的做法是在解除前核对该仓库的关联记录是否已满足留档需要，把需要长期追溯的提交与合并请求条目确认清楚，再执行解除。
解除关联和删除工作项，对数据的影响一样吗？
不一样。手册对“移除代码仓关联”的描述是停止获取新提交、保留历史已获取数据；删除工作项或删除项目属于另一类资源操作，手册未将其与解除关联等同，不能套用“保留历史”的结论，需按对应规则确认。
在 GitHub 侧删除仓库同样是与 ONES 侧移除关联不同的两件事，前者影响平台上的代码与事件源。
多个 GitHub 账号下仓库很多，接入时怎么分批？
手册描述一次最多获取 100 个仓库，可按账号拆分关联。这里的 100 是 ONES 的获取范围，不是 GitHub 平台的仓库总上限。
实践上可以按账号划分批次，每个账号作为一批完成关联，并记录该批覆盖的仓库清单。这样后续某个仓库下线时，能快速定位它属于哪一批、关联了哪些工作项。
接入或解除前，权限和部署上要先确认什么？
接入环节需要代码集成配置权限，在配置中心启用代码集成、新增关联仓库并完成 OAuth 认证后选择仓库。OAuth 用于取得配置仓库 Webhook 的权限，权限不足时需手工配置 Webhook。
使用私有部署版 ONES 接入 GitHub 时，手册要求先联系 ONES 完成基础配置，且不要与接入私有 GitLab 的流程混用。具体仓库权限以代码平台和 ONES 当前文档为准。
官方参考资料
- GitHub/公有 GitLab（ONES）
