账本：Copilot 智能体 14.5 周重写 Rust 的 TaoToken Key 消耗
2026/9/18 5:02:53
CANN 社区 GitCode 仓库协作与 PR 合入门禁 FAQ：fork、分支保护、机器人评论命令与 CI 触发全解
【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息，包括不限于：会议日程，成员信息，服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure
CANN 社区的所有开源仓库均托管于 GitCode，并围绕 fork + Pull Request（PR）+ 机器人评论 + CI 流水线构建了一套完整的协作与合入门禁体系。本文以 CANN 基础设施团队维护的 infra-faqs.md 为核心，系统解答开发者在使用 CANN 仓库过程中最常遇到的 6 类问题：同名仓库 fork 失败、保护分支与非保护分支、直接 push 与评论合入的区别、评论区机器人命令语义，以及 PR 不触发 CI 的处理方法，并结合仓库内的机器人能力文档、CI 配置指导与 SDLC 安全规范做源码级纵深说明。读完本文，你将能独立完成 CANN 仓库的代码贡献全流程排障，并理解社区为什么要求"人人走 PR、评审必留痕"。
一、为什么不能 fork 一个 CANN/abc 仓库到个人账号下？
1.1 现象与原因
在 GitCode 上尝试 fork CANN 组织的仓库（例如CANN/abc）到个人账号时，有时会直接失败。根据 infra-faqs.md 中的官方说明，这类问题几乎总是因为个人账号下已经存在同名仓库（例如你之前已经从 CANN 组织 fork 过一个名为abc的仓库）。
根本原因是 GitCode 的仓库寻址机制：平台通过"个人账号名 + 仓库名"来唯一定位一个仓库。因此，同一账号下不允许出现两个同名仓库，否则地址会发生冲突，平台便拒绝执行 fork 操作。
1.2 解决方案
- 进入个人账号下已存在的同名仓库（如
yourname/abc）； - 修改该仓库的名称（和/或路径），使其与待 fork 的
CANN/abc不再重名； - 重新回到
CANN/abc仓库页面执行 fork 即可。
提示：fork 的目的是在个人账号下获得一份可自由修改的副本，之后通过提交 PR 的方式将改动贡献回 CANN 主仓。因此 fork 前建议先检查个人仓库列表中是否已有同名仓库，避免无谓的反复操作。
二、保护分支与非保护分支的区别
2.1 核心区别
| 维度 | 保护分支（Protected Branch） | 非保护分支（Unprotected Branch） |
|---|---|---|
| 推送权限 | 可设置特定角色或成员才拥有推送（push）权限 | 不支持设置，符合条件的人员均可推送 |
| 合并权限 | 可设置特定角色或成员才拥有合并（merge）权限 | 不支持设置 |
| 典型用途 | 承载主干代码的master/main等发布分支 | 日常开发、临时分支、大文件中转分支 |
2.2 为什么默认分支必须保护？
这一点在 CANN 基础设施团队的 社区基础设施软件开发生命周期治理与安全规范V1.0（4.3 开发编码阶段）中被明确为【MUST】 强制要求：
代码仓库的默认分支必须开启保护机制。禁止包括管理员在内的任何角色直接推送代码。所有变更必须通过 Pull Request（PR）发起，且需满足"人工审核通过"与"自动化流水线（扫描、测试）通过"双重条件方可合入。
其背后的安全逻辑是：默认分支承载核心业务逻辑，直接推送极易引入未经核实的故障或漏洞；通过强制 PR 合入，可以利用代码评审拦截缺陷，并依托自动化检测屏蔽风险代码，同时保证核心代码库的审计记录完整可追溯。
三、CANN 开发者角色可以直接 push 代码到社区仓库吗？
不可以。根据 infra-faqs.md 的明确说明：
- CANN 开发者不允许直接 push 代码到社区仓库；
- 只有仓库管理员（以及被授权到保护分支的角色）才能直接 push；
- CANN 开发者若想贡献代码，只能先 fork 社区仓库到个人账号，然后在个人副本上开发，最后通过提交 Pull Request 的方式将改动贡献回主仓。
这与上一节的分支保护策略是一脉相承的：无论贡献者身份如何，主干代码的变更都必须经过 PR 流程，在评审与自动化门禁双重把关下合入，而不是绕过审查直接写入。
四、直接 push 代码 vs 评论 /lgtm、/approve 合入代码
4.1 两种方式的本质差异
| 对比项 | git 直接 push | 评论 /lgtm、/approve 合入 |
|---|---|---|
| 审核环节 | 无 | 有（至少 1 位 committer 评审） |
| 合入风险 | 较高 | 较低 |
| 适用场景 | 文件过大超过个人仓库限制等特殊场景 | 常规代码贡献 |
| 合入路径 | 先 push 到非保护分支，再向保护分支发起 merge | 通过 PR + 机器人评论打标签自动合入 |
4.2 直接 push 的适用场景
直接 push 虽然缺少必要的审核环节、存在一定合入风险，但社区并未完全禁止，其典型应用场景是：需要上传的文件过大，超过了个人仓库的限制。此时可将大文件先直接 push 到仓库的非保护分支，然后再通过"非保护分支 → 保护分支"的 merge 流程完成合入。
4.3 评论合入的评审保证
通过评论/lgtm、/approve合入代码，从流程上增加了评审环节，保证一份代码的合入至少需要提交者以外的一位 committer 的评审同意——即便提交者本人就是 committer，也需要另一位 committer 同意才能合入。
这背后对应 CANN 社区机器人（CANN-robot）的完整标签机制，详见 docs/robot/robot能力列表.md：
/lgtm：添加代表"代码已评审"的lgtm标签，执行人为仓库所属 SIG 组的 committer；/approve：添加代表"committers 同意合并"的approved标签，默认采取squash 合并方式，执行人为仓库所属 SIG 组的 committers；/check-pr：检查 PR 中的标签是否满足合入条件，满足则自动合并 PR。
注意lgtm与approved是两个不同层级的门禁：lgtm代表代码评审通过，approved代表合并决策通过，两者都需要由具备对应权限的 committer 发出评论，机器人负责打标签与执行合入动作。
五、CANN 社区仓库评论区支持哪些命令？
CANN 社区中所有项目均由 Bot 维护，开发者可以在每个 Pull Request 或 Issue 下通过评论触发 Bot 命令。完整的命令清单参见 CANN社区评论命令一览，以下是核心命令速查：
5.1 PR 合入门禁类命令
| 命令 | 示例 | 使用范围 | 描述 | 面向对象 |
|---|---|---|---|---|
/check-cla | /check-cla | PR | 强制重新检查 PR 的 CLA 状态；已签署则加cann-cla/yes，否则加cann-cla/no | 所有开发者 |
/cla cancel | /cla cancel | PR | 强制删除cann-cla/yes标签 | 仓库管理员 |
/compile | /compile | PR | 触发编译 CodeArts 流水线；通过打ci-pipeline-passed，失败打ci-pipeline-failed | 所有开发者 |
/lgtm | /lgtm | PR | 添加代表代码已评审的lgtm标签 | 仓库所属 SIG 组的 committer |
/lgtm cancel | /lgtm cancel | PR | 移除lgtm标签 | 仓库所属 SIG 组的 committer |
/approve | /approve | PR | 添加代表 committers 同意合并的approved标签，默认 squash 合并 | 仓库所属 SIG 组的 committers |
/approve cancel | /approve cancel | PR | 移除approved标签 | 仓库所属 SIG 组的 committers |
/check-pr | /check-pr | PR | 检查 PR 标签是否满足条件，满足则合并 PR | 任何人 |
/merge | /merge | PR | 添加代表 branch_keeper 同意合并的keeper_approved标签 | 仓库对应分支的 branch_keeper |
5.2 Issue / PR 标签与协作类命令
| 命令 | 示例 | 使用范围 | 描述 | 面向对象 |
|---|---|---|---|---|
/kind ** | /kind bug | PR / Issue | 添加kind/bug等分类标签（标签需已存在于仓库） | 仓库管理员可直接添加，其他人评论添加 |
/remove-kind ** | /remove-kind bug | PR / Issue | 移除kind/bug标签 | 所有人 |
/priority ** | /priority high | PR / Issue | 添加priority/high等优先级标签 | 仓库管理员可直接添加，其他人评论添加 |
/remove-priority ** | /remove-priority high | PR / Issue | 移除优先级标签 | 所有人 |
/sig ** | /sig AI | PR / Issue | 添加sig/AI等 SIG 归属标签 | 仓库管理员可直接添加，其他人评论添加 |
/remove-sig ** | /remove-sig AI | PR / Issue | 移除 SIG 标签 | 所有人 |
/assign [[@]...] | /assign @cann-robot | Issue | 为 Issue 指派负责人 | 所有人 |
/unassign [[@]...] | /unassign @cann-robot | Issue | 取消 Issue 指派负责人 | 所有人 |
/label add ** | /label add bug resolved | PR / Issue | 添加一个或多个指定标签（空格分隔） | 所有人 |
/label remove ** | /label remove bug resolved | PR / Issue | 删除一个或多个指定标签（空格分隔） | 所有人 |
命令参数规则：
/kind、/priority、/sig等命令可接受大小写字母、数字、中划线、下划线。需特别注意的是，通过评论添加的标签必须已存在于仓库中，否则无法打上。
5.3 机器人 Issue 自动处理规则
除 PR 评论命令外，机器人还会对 Issue 做自动化生命周期管理（详见 docs/robot/robot能力列表.md），相关规则（标签名、超时天数、评论模板）统一维护在 bot-issue-manage.yaml 配置文件中：
| 配置项 | 默认值 | 含义 |
|---|---|---|
label_resolve | resolved | 标识 Issue 已解决的标签 |
label_stale | stale | 标识 Issue 进入闲置状态的标签 |
label_wait_feedback | wait-feedback | 标识正在等待 Issue 提交者反馈的标签 |
resolve_to_stale_days | 7 | resolved 后允许的最大未更新天数，超时自动标记 stale |
stale_to_close_days | 14 | stale 后允许的最大未更新天数，超时自动关闭 |
wait_feedback_to_warn_days | 7 | wait-feedback 后负责人已回复但提单人未回复，超时发预警 |
wait_feedback_to_close_days | 14 | 预警后提单人继续沉默超时，自动关闭 |
stale_comment/wait_feedback_warn_comment/wait_feedback_close_comment | 见配置文件 | 各阶段机器人自动发布的提示评论模板 |
规则新增与调整步骤为：修改 bot-issue-manage.yaml → 提交 PR → PR 合入后机器人配置在每轮任务执行前自动刷新生效。注意确保目标仓库中已存在配置的标签，否则机器人可能无法成功执行打标动作。
六、提交 PR 后没有触发 CI 构建，如何处理？
这是贡献者最常遇到的问题之一。根据 infra-faqs.md，CI 未及时触发通常有两种情况：
6.1 情况一：webhook 通知延迟或丢失
- 原因：网络原因或系统任务调度原因，导致从代码仓库发出的 webhook 通知事件没有及时到达目标服务，因此没有触发 CI 构建。
- 处理：在 PR 评论区评论
/compile手动重新触发编译流水线。
6.2 情况二：CI 构建工程尚未创建
- 原因：代码仓库创建后短时间内就提交了 PR，此时系统尚未为该仓库创建 CI 构建工程，因此触发不到 CI 构建。
- 处理：此时评论
/compile也不生效，请稍等片刻，待系统自动完成构建工程创建后再触发。
6.3 CI 流水线的触发机制
从 CI 配置侧看，CANN 仓库的编译流水线正是通过 PR 评论触发的。参考 CI流水线配置指导.md 中的触发配置：
on: pr_comment: types: [ created ] keyword: '^(?:\/)?compile*' pull_request_comment: types: [created] branches: [ '*' ] comments: [ '^(?:\/)?compile*' ]其中pr_comment用于标识预合并（pre-merge）流水线，pull_request_comment的comments字段以正则过滤决定何时启动流水线。这也解释了为什么评论/compile是手动重新触发 CI 的标准入口。
6.4 CI 触发后的检查项
流水线触发后，会按"静态检查、编译构建、测试"三类执行一系列检查项，详见 docs/ci/ci_guide.md：
| 任务分类 | 任务项示例 | 说明 |
|---|---|---|
| 静态检查 | codecheck_{xxx}、antiposion_{xxx}、SCA_{xxx}、API_Check、codecheck_precommit等 | 安全类检查（敏感信息、代码注入等）、恶意文件扫描、开源合规检查、API 兼容性校验、代码规范检查 |
| 编译构建 | Compile_{xxx}_X86、Compile_{xxx}_ARM | X86 / ARM 平台源码编译、依赖拉取、可执行文件生成 |
| 单元测试 | UT_{xxx} | 核心函数/模块单测，通过标准为用例无失败且覆盖率不低于仓库预设阈值 |
| 系统测试 | ST_{xxx} | 基于完整系统部署环境验证多模块协同 |
| 冒烟测试 | PreSmoke_{xxx} | 按芯片型号拆分，快速验证核心功能可用性 |
流水线结束后，机器人会自动在 PR 评论区写入汇总评论（last_comment），包含成功/失败明细、失败日志、编译产物、覆盖率/检查报告链接等；开发者可据此快速定位问题。若 CI 运行中遇到流水线触发失败、静态检查失败、单元测试覆盖率不足等问题，可查阅 CANN社区CI工程FAQ 获取对应解决方案。
七、关于机器人评论与 CI 的常见延伸排障
以下排障要点来自 docs/robot/robot使用指南.md 与 infra-sdlc-guidelines.md，是评论区命令与 CI 门禁配套使用时的常见坑位：
7.1 评论 /lgtm、/approve 后没有自动打标签
- 核对身份与 ID：确认评论人是对应模块的 maintainer / committer，并仔细对比评论人的 gitcode-id 与仓库
sig-info.yaml中填写的 gitcode-id（区分大小写）。若 ID 不一致，需要提 PR 修改sig-info.yaml，合入约 10 分钟后权限生效，再重新评论。 - 核对数量：一般情况下，PR 涉及的每个模块都需要 1 个 committer/maintainer 评论
/lgtm和 1 个 committer 评论/approve才能打上标签。 - 核对评论时间：若评论时间早于 PR 最新 commit 的时间，评论无效（常见原因是提交代码机器的时间与实际时间不一致），需修正机器时间后回退至上一 commit 重新提交。
- 排除网络波动：以上均确认无误仍不打标签时，可能是网络波动，等待 1 分钟重新评论触发即可。
7.2 PR 标签足够却没有自动合入
机器人会评论相应的提示信息，常见情形包括：
| 提示信息 | 原因 | 处理建议 |
|---|---|---|
| "Do not meet the condition of Fast-forward Merge, please do the rebase." | PR 合并模式要求 fast-forward 条件（commits 均基于目标分支最新 commit 提交） | 基于目标分支最新 commit rebase 代码，或联系管理员调整 PR 合并模式 |
| "You do not have permissions to push into target branch" | 机器人账号没有合入该分支 PR 的权限 | 联系管理员授予机器人账号合入对应分支 PR 的权限 |
| "Failed to squash..." | PR 代码与目标分支最新代码存在冲突 | 按评论提示解决冲突后重新 push |
| "git update-ref: exit status 128..." | 同一时间、同一仓库、同一分支另有 PR 正在合入（并发） | 等待约 1 分钟后再次评论/check-pr触发合入 |
| "The MR can not be merged, because of this MR is work in process." | PR 标题以[WIP]开头 | 删除标题中的[WIP] |
| "CodeReview discussion not resolved." | PR 存在未解决的评审意见 | 先解决全部评审意见 |
| "The following labels are not ready..." | 非机器人账号添加的标签无效 | 先移除手动打的标签，再评论对应指令让机器人重新打标 |
7.3 与合入门禁相关的安全底线
CANN 基础设施团队将代码合入门禁写入了 社区基础设施软件开发生命周期治理与安全规范V1.0，其中与 PR 流程强相关的【MUST】 项包括：默认分支必须保护（禁止任何角色直接推送）、贡献者必须签署 CLA、CI/CD 流水线必须集成 SAST 静态安全扫描与密钥扫描（PR 阶段实时增量扫描 + 全量分支周期性扫描，识别到硬编码凭证自动阻断合入）。这也从治理层面解释了"直接 push 不可取、评论合入是正道"的根本原因。
八、遇到问题如何寻求支撑
当 FAQ 未覆盖你的问题、或流水线/机器人出现异常时，可按以下渠道求助（详见 docs/services.md）：
- 基础设施支撑矩阵：覆盖新建流水线、CLA 签署、CANN-robot、社区邮件列表、社区会议、漏洞管理服务、CANN 数字化协作平台、静态检查、AI 技能（门禁 CI 排障）等支撑项，每项均列出了对应的 GITCODE 账号与邮箱，可直接联系对应支撑人；
- 组件仓库 CIE 支撑矩阵：遇到编译构建异常、UT 执行异常、冒烟测试任务异常、静态检查结果屏蔽审核、代码合入异常等问题时，优先联系对应组件仓库的 CIE（持续集成工程师）处理。
结语
CANN 社区的仓库协作体系可概括为一条主线：fork 个人副本 → 开发 → 提交 PR → 评论/compile触发 CI → 评论/lgtm、/approve完成评审 → 标签齐备后由机器人自动合入。理解 infra-faqs.md 中的 6 个高频问题，再配合 机器人命令一览、CI 工程检查项 与 SDLC 安全规范 使用，即可顺畅完成从提码到合入的完整闭环，并在遇到门禁异常时快速自助定位。
【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息，包括不限于：会议日程，成员信息，服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考