给 CPF-Flutter / CPF-rn / CJMP 等组织贡献 PR 的完整流程

红目香薰

223人浏览 · 2026-09-07 20:42:36

红目香薰 · 2026-09-07 20:42:36 发布

本文以 CPF-Flutter/skills 仓库 PR #45（docs: HarmonyOS SDK 版本动态读取，替代硬编码，已合入）为真实案例，完整梳理向 CPF-Flutter、CPF-rn、CJMP 等组织仓库贡献 Pull Request（合并请求）的端到端流程，涵盖 fork、分支、提交规范、Issue、PR、机器人评审、测试与合入全环节，并附踩坑清单与时间线复盘。

背景：目标组织与仓库
全流程总览
前置准备
阶段一：Fork 与本地环境
阶段二：新建功能分支
阶段三：编写提交（commit 规范）
阶段四：推送到自己的 fork
阶段五：先创建 Issue
阶段六：创建 PR
阶段七：关联 PR 与 Issue
阶段八：触发 CI 构建
阶段九：机器人评审（AI 检视）
阶段十：处理评审意见（修订提交）
阶段十一：测试与合入
合入后收尾
案例复盘：PR #45 完整时间线
常见问题与踩坑清单
附录：模板与命令速查

1. 背景：目标组织与仓库

以下组织面向 OpenHarmony / HarmonyOS 生态的开源协作，通过 Fork PR 模式 接受社区贡献：

组织	仓库	定位	典型分支
CPF-Flutter	skills	Flutter 三方库鸿蒙适配的 Copilot SKILL 技能仓	`main`
CPF-rn	skills	React Native（RNOH）鸿蒙化技能仓	`main`
CJMP	VibeCoding	仓颉（Cangjie）跨平台开发技能仓	`main`

这些仓库的特点：

纯技能/文档型仓库：内容以 SKILL.md + references/ 目录为主，大部分 PR 是文档与规范修订（如 PR #45 就是文档修订），但也有新增/重构技能的 feat 类 PR。
自动化程度高：有 openharmony_ci（CI/测试机器人）和 cpf-manager（AI 评审机器人）自动巡检每个 PR，合入条件严格。
全程 AtomGit 托管：Issue、PR、评审、测试都在 AtomGit（atomgit.com）完成。

案例 PR #45：仓库 CPF-Flutter/skills，标题 docs: HarmonyOS SDK 版本动态读取（compatibleSdkVersion/targetSdkVersion/目录名），替代硬编码，由 jianguoxu（坚果）从 fork jianguoxu/skills 的分支 fix/sdk-version-dynamic-read 提交，目标分支 main，对应 issue #25，最终合入。

2. 全流程总览

整个贡献流程可以拆成 11 个阶段，两端（发起与收尾）在本地 git 完成，中间（Issue/PR/评审/合入）在 AtomGit 网页端完成：

阶段	做什么	在哪里	耗时
0	前置准备（账号/Token/git 配置）	本地	一次性
1	Fork 组织仓库	AtomGit 网页	1 分钟
2	新建功能分支	本地	1 分钟
3	编写改动并提交（commit 规范）	本地	看工作量
4	推送到自己的 fork	本地	1 分钟
5	创建 Issue（先于 PR）	AtomGit 网页/API	5 分钟
6	创建 PR	AtomGit 网页/API	5 分钟
7	关联 PR 与 Issue	AtomGit 网页/API	1 分钟
8	触发 CI 构建	PR 评论 `start build`	即时
9	机器人评审（DCO + AI 检视 + 行内评论）	自动	分钟级
10	处理评审意见，追加修订提交	本地 + 推送	按意见量
11	测试通过 + 合入 + 收尾	AtomGit 网页	分钟级

核心原则：小步提交、描述清晰、评审意见逐条回应、不自己合自己的 PR。

3. 前置准备

3.1 账号与访问令牌

注册 AtomGit 账号，建议开启两步验证。
在「个人设置 → 私人令牌」生成一个访问令牌（ATOMGIT_TOKEN），用于 API 创建 Issue/PR 和 CI 触发。令牌只保存在本地环境变量中，绝不写入代码或提交。

export ATOMGIT_TOKEN="你的令牌"

3.2 git 身份配置（DCO 签名前置）

这些组织的仓库强制 DCO（Developer Certificate of Origin）检查：每个提交必须带 Signed-off-by: 签名行（git commit -s），而签名行的姓名/邮箱取自 git 的 user.name / user.email。因此提交前必须正确配置：

git config --global user.name "你的名字"          # 例：坚果
git config --global user.email "你的邮箱"         # 例：jianguo@nutpi.net

案例 PR #45 的提交中，作者与签名均为 坚果 <jianguo@nutpi.net>，DCO 检查通过后 PR 被自动打上 dco检查成功 标签。

3.3 提交信息偏好（以仓库规范为准）

commit message 使用英文，一句话精简摘要，带 Conventional Commits type 前缀（docs: / feat: / fix: / chore: / refactor: 等）。
提交末尾可附加 Co-Authored-By: 名字 <邮箱> 标注协作作者。
签名行由 -s 自动生成。

4. 阶段一：Fork 与本地环境

4.1 Fork 组织仓库

打开目标仓库（如 https://atomgit.com/CPF-Flutter/skills），点击 Fork，将仓库复制到自己的命名空间下（如 jianguoxu/skills）。

在这里插入图片描述

4.2 本地 clone 并配置双 remote

关键点：本地需要两个 remote —— 组织仓库（公仓）和你自己的 fork（私仓），便于随时同步上游、向 fork 推送。

# clone 自己的 fork（默认 remote 名 origin 指向 fork）
git clone https://atomgit.com/jianguoxu/skills.git
cd skills

# 将组织仓库添加为另一个 remote（以 origin/fork 命名，便于识别）
git remote add origin https://atomgit.com/CPF-Flutter/skills.git   # 组织公仓
git remote add fork https://atomgit.com/jianguoxu/skills.git       # 自己的 fork

实际案例中本地仓库的 remote 配置如下（来自贡献者工作环境）：
origin  https://atomgit.com/CPF-Flutter/skills.git   (fetch/push)
fork    https://atomgit.com/jianguoxu/skills.git     (fetch/push)

remote 命名约定（与组织 ohos-flutter-submit-code 技能的识别规则一致）：

公仓：remote 名称为 upstream 或 origin，通常指向组织仓库（CPF-Flutter/...、CPF-rn/...、CJMP/...）。
私仓：其余 remote（通常以贡献者名字命名，如 fork、zhangsan）。
若同时有 upstream 与 origin，优先将 upstream 视为公仓。

4.3 保持 main 与上游同步

每次开始新贡献前，先同步 fork 与本地：

git fetch origin main
git checkout main
git merge origin/main          # 或 git pull origin main
git push fork main             # 保持 fork 的 main 也最新

5. 阶段二：新建功能分支

绝不直接在 main 上改代码、发 PR。每次贡献建一个独立分支，命名反映改动类型与内容：

前缀	含义	案例（本仓库真实分支）
`feat/`	新功能/新技能	`feat/flutter-issue-demo-reproduction-enhance`
`fix/`	修复/改进	`fix/sdk-version-dynamic-read`
`docs/`	文档修订	`docs/xxx`
`chore/`	工具链/杂项	—

# 从最新的 main 拉出分支
git checkout main
git pull origin main
git checkout -b fix/sdk-version-dynamic-read

案例 PR #45 的分支名 fix/sdk-version-dynamic-read 准确描述了「修复 SDK 版本硬编码、改为动态读取」的意图。

6. 阶段三：编写提交（commit 规范）

6.1 只提交必要的文件

先检查工作区状态，确认没有把临时文件带进提交：

git status --short
git diff --stat

⚠️ 案例教训：PR #45 曾经误提交了一个临时文件 COMMIT_MSG.txt（commit message 草稿），被 AI 评审机器人在行内评论中标记为「一般」严重级别问题、要求合入前删除，最终作者追加了一个 chore: remove accidentally committed COMMIT_MSG.txt 提交才解决问题。提交前务必确认没有混入草稿、日志、构建产物等无关文件。

6.2 撰写 commit message

规范：

英文、一句话精简摘要；
带 Conventional Commits type 前缀：feat / fix / docs / refactor / perf / test / chore / revert；
需要时补充正文，逐条列出改动点（尤其当它是「回应评审意见」的修订提交时）；
结尾由 -s 自动添加 Signed-off-by: 签名行（DCO）。

git add <改动的文件>
git commit -s -m "docs: read HarmonyOS SDK version dynamically instead of hardcoding

HarmonyOS SDK version should be read from the project's
ohos/build-profile.json5 (compatibleSdkVersion / targetSdkVersion)
or the local SDK install directory rather than hardcoded values.

Co-Authored-By: AtomCode <jianguo@nutpi.net>
Signed-off-by: 坚果 <jianguo@nutpi.net>"

6.3 案例 PR #45 的三个提交

PR #45 合入时共 3 个提交，展示了「主提交 → 回应评审 → 清理误提交」的典型结构：

提交	类型	说明
`53acc99`	`docs:`	主改动：SDK 版本动态读取，修改 5 个 references 文档
`6f22f89`	`docs:`	回应评审：逐条落实评审意见（[一般]/[建议] 级别），补充 Windows 路径示例等
`14e95ef`	`chore:`	清理：删除误提交的 COMMIT_MSG.txt

7. 阶段四：推送到自己的 fork

推送到 fork（私仓）分支，而不是直接推组织仓库：

git push fork fix/sdk-version-dynamic-read

推送被拒绝（分支分叉）时的处理：

先 fetch 评估分叉程度：

git fetch fork
git log --oneline --left-right fork/fix/sdk-version-dynamic-read...HEAD

安全方案优先：推一个新分支（如 fix/sdk-version-dynamic-read-2）再从新分支发 PR；
仅当确认 fork 远端独有提交可以丢弃（已被合入公仓或废弃实验）时，才用 --force-with-lease 强推：
```
git push --force-with-lease fork fix/sdk-version-dynamic-read
```
绝不盲目 git push --force——会丢失远端独有提交。

8. 阶段五：先创建 Issue

顺序不能反：先建 Issue，再建 PR，最后关联。 组织仓库要求每个 PR 关联一个配套 Issue（close_related_issue 开启时，PR 合入后 Issue 自动关闭）。

8.1 为什么先建 Issue

Issue 承载「问题/提案」的完整描述，PR 引用它形成闭环（合入后自动关闭）；
评审机器人和维护者能通过 Issue 快速理解 PR 的动机与影响范围；
与组织仓库的 ohos-flutter-submit-code 技能流程一致：先创建 Issue，创建后立即关联。

8.2 Issue 内容（中文）

标题：与 commit message 一致（含 type 前缀）。
正文：按提交类型选择模板（组织仓库有配套的 ISSUE_TEMPLATE），一律中文（技术术语可保留英文）。
label：按 commit type 打对应标签（bug / feature / documentation / performance / CICD 等），优先使用公仓现有 label。

模板选择表：

commit type	Issue 模板	关键章节	label
`fix`	模板 A（报告 Bug）	复现步骤 / 期望结果 / 实际结果 / 复现 Demo / 日志 / 环境信息	`bug`
`feat`	模板 B（功能请求）	使用场景 / 提案 / 实现方案 / 环境信息	`feature`
`perf`	模板 C（性能）	复现步骤 / 性能数据 / 复现 Demo / 目标平台 / 环境信息	`performance`
`docs`	模板 D（设计文档）	文档链接 / 解决什么问题 / 变更内容 / 环境信息	`documentation`
`chore`	模板 E（基础设施）	需要什么帮助 / 描述 / 环境信息	`CICD`
`test`/`refactor`	模板 F（通用简化）	问题概述 / 变更内容 / 环境信息	`test` / `refactor`

案例 issue #25（PR #45 的配套 Issue）：标题为「建议：HarmonyOS SDK 版本应动态读取 compatibleSdkVersion/targetSdkVersion 或 SDK 目录名，而非硬编码」，正文包含「问题描述（逐文件列出硬编码位置）→ 建议方案（按优先级 1/2/3）→ 对应修改点 → 影响范围 → 参考」，非常完整，维护者/评审机器人可以据此快速核对 PR 是否落实。

8.3 用 API 创建 Issue（可选）

PR 创建环节也可以用 API 自动化（与 ohos-flutter-submit-code 技能一致）。注意：body 含换行/引号，必须写临时 JSON 文件再 curl -d @file，不要内联 JSON：

cat > /tmp/create_issue.json <<'EOF'
{
  "title": "docs: ...",
  "body": "## 问题描述\n...",
  "labels": "documentation"
}
EOF

curl -s -X POST "https://api.atomgit.com/api/v5/repos/CPF-Flutter/skills/issues" \
  -H "Content-Type: application/json" \
  -H "PRIVATE-TOKEN: $ATOMGIT_TOKEN" \
  -d @/tmp/create_issue.json

成功后记录返回的 number（Issue 编号）与 html_url。

9. 阶段六：创建 PR

9.1 页面创建（推荐首选）

在 AtomGit 上创建 PR（页面称「合并请求 Merge Request」，URL 为 /pull/<编号> 或 /merge_requests/<编号>）：

源分支（head）：jianguoxu/skills:fix/sdk-version-dynamic-read（fork 名:分支名）
目标分支（base）：CPF-Flutter/skills:main
标题：与 commit message 一致（含 type 前缀）——案例标题为 docs: HarmonyOS SDK 版本动态读取（compatibleSdkVersion/targetSdkVersion/目录名），替代硬编码
正文：按仓库模板填写（见 9.2）
关联 Issue：勾选/填写 issue 编号，并开启「合入后关闭关联 Issue」（close_related_issue）

9.2 PR 正文结构（案例实际使用的结构）

PR #45 的正文使用如下结构（中文，与 skills 仓库的文档型 PR 风格一致）：

章节	内容要点
## 概述	对应 issue #25，一句话说明改动目标
## 修改内容	表格：每个改动文件 → 具体改动说明
## 动机	为什么改：硬编码的版本滞后/易出错/不可复现三大问题
## 测试	纯文档改动不影响行为逻辑的说明

## 概述

对应 issue #25：HarmonyOS SDK 版本应动态读取 compatibleSdkVersion / targetSdkVersion
（或 ~/Library/OpenHarmony/Sdk/<version>/ 目录名），而非硬编码 5.0.0(12)。

## 修改内容

| 文件 | 改动 |
|------|------|
| `flutter-library-document-optimization/references/规范-结构.md` | 兼容性字段 SDK: 补充动态读取说明 |
| `...` | ... |

## 动机

硬编码 SDK 版本号存在版本滞后、易出错、不可复现三个问题；改为从工程配置
（ohos/build-profile.json5）或本机 SDK 安装目录动态读取，可保证文档/报告与实际
测试环境一致。

## 测试

纯文档/规范说明改动，不影响 skill 行为逻辑。

注意：部分组织仓库（如 flutter_flutter 引擎仓）的 PR 模板是英文的（## Why are these changes being made? / ## Changelog / ## Test Plan / ## Checklist），提交前先看目标仓库的 PR 模板（.atomgit/PULL_REQUEST_TEMPLATE 或创建 PR 页面自动填充的模板），以仓库模板为准。

不要在 PR 正文重复写 Signed-off-by:——commit 里已有 DCO 签名，PR 描述重复是冗余。

9.3 用 API 创建 PR（可选）

cat > /tmp/create_pr.json <<'EOF'
{
  "title": "docs: ...",
  "body": "## 概述\n...",
  "head": "jianguoxu:fix/sdk-version-dynamic-read",
  "base": "main"
}
EOF

curl -s -X POST "https://api.atomgit.com/api/v5/repos/CPF-Flutter/skills/pulls" \
  -H "Content-Type: application/json" \
  -H "PRIVATE-TOKEN: $ATOMGIT_TOKEN" \
  -d @/tmp/create_pr.json

head 格式为 <私仓owner>:<源分支>；
响应字段存在混用（iid/number、web_url/html_url），提取编号与链接时按兼容方式处理。

10. 阶段七：关联 PR 与 Issue

创建 PR 后立即把配套 Issue 关联到 PR：

curl -s -X POST "https://api.atomgit.com/api/v5/repos/CPF-Flutter/skills/pulls/45/issues" \
  -H "Content-Type: application/json" \
  -H "PRIVATE-TOKEN: $ATOMGIT_TOKEN" \
  -d "[25]"      # JSON 数组，即使只有一个 issue 也用数组

⚠️ 关联后必须核对关联列表：AtomGit 会自动扫描 PR 标题/描述/commit 中的 issue、#数字、fix、close 等关键词并自动关联历史 Issue（例如 skill 名里带 “issue” 字样时极易误关联）。关联后查询一次：

curl -s "https://api.atomgit.com/api/v5/repos/CPF-Flutter/skills/pulls/45/issues" \
  -H "PRIVATE-TOKEN: $ATOMGIT_TOKEN"

关联列表应只有本次的 Issue 编号；
发现多余关联：先尝试 API 删除（DELETE /pulls/:number/issues，传多余编号数组）；若 API 删除不生效（系统自动关联无法用 API 移除），到网页端 PR 页面手动移除。

11. 阶段八：触发 CI 构建

在 PR 评论中发 start build 触发 CI 构建（组织规范要求所有 PR 一律触发，不区分仓库类型与 commit type）：

cat > /tmp/start_build.json <<'EOF'
{"body": "start build"}
EOF

curl -s -X POST "https://api.atomgit.com/api/v5/repos/CPF-Flutter/skills/pulls/45/comments" \
  -H "Content-Type: application/json" \
  -H "PRIVATE-TOKEN: $ATOMGIT_TOKEN" \
  -d @/tmp/start_build.json

注意：PR 评论必须用专门的 pulls 评论端点（/pulls/:number/comments），不要用 issues 评论端点。

12. 阶段九：机器人评审（AI 检视）

创建 PR 并触发构建后，两个机器人会自动开始巡检，无需人工介入：

12.1 openharmony_ci —— CI / DCO / 测试机器人

PR 创建瞬间即回复「感谢提交 Pull Requests！」；
自动执行 DCO 检查，通过后给 PR 打 dco检查成功 标签；
后续负责执行测试并报告结果（「添加测试通过成功！」），以及校验合入条件（「该 pr: … 不满足合入条件」）。

12.2 cpf-manager —— AI 评审机器人

对涉及 skill 的 PR，cpf-manager 会输出一份 《Skill PR 检视报告》，这是组织仓库特有的评审环节：

评分协议：按 8 个维度打分（知识增量 / 思维与流程 / 反模式质量 / 规范合规 / 渐进式披露 / 自由度校准 / 模式识别 / 实用可用性），满分 120 分，评级 A/B/C；
合入建议标准：涉及的所有 Skill 评分 ≥ B 级才建议合入，任一 C 级则「暂缓合入」；
行内评论：在 diff 的具体代码行上留评论，带严重级别标记（【AI-Review】【一般】、【建议】 等），评论可标记 resolved（已解决）；
结论部分：给出「✅ 合理的变更 / ⚠️ 需修复的问题 / 合入建议」，问题按严重程度（高/中/低）排序。

案例 PR #45 的实际评审过程：

首轮检视报告：两个受影响 Skill（cpf-ohos-issue-analysis、flutter-library-document-optimization）评分 B 级，建议合入，同时列出 Critical Issues 与 Top 3 改进建议；
行内评论指出「COMMIT_MSG.txt 是临时提交信息文件误入仓库（status: added）」，严重级别【一般】，要求 git rm COMMIT_MSG.txt 保持仓库纯净；
复检报告（作者补交修订提交后）：指出 COMMIT_MSG.txt 仍在 diff 中以 added 状态存在，属【高】严重问题，合入建议改为「暂缓合入」，要求合入前必须删除该文件；
作者追加 chore: remove accidentally committed COMMIT_MSG.txt 提交后问题解决，相关行内评论标记 resolved: true。

要点：机器人评审是硬性门槛，不是走过场。逐条回应、逐条解决，否则 PR 无法合入。

13. 阶段十：处理评审意见（修订提交）

13.1 评审意见的回应方式

行内评论：可以在网页端逐条回复说明处理方案，或直接通过追加提交修复；
修订提交：在本分支继续追加提交，不要改写已推送的历史（避免 force push）；
逐条落实：commit message 中明确列出回应的每一条评审意见（带严重级别），方便评审人复查。

案例 PR #45 的修订提交（6f22f89）的 commit message 结构（很好的范本）：

docs: address review feedback on SDK version dynamic read

Address PR review comments before merge:

- [一般] Resolve internal hardcoding contradictions in
  ohos-signing-config.md (lines 117-120, 136): consistently instruct
  reading compatibleSdkVersion/targetSdkVersion from the project's
  ohos/build-profile.json5 first, falling back to the default only when
  unset and marking it as "default, not measured".
- [建议] Add Windows SDK install path example to 规范-结构.md and
  environment-info.md (macOS / Windows / Linux paths).
- [建议] Add fallback strategy in environment-info.md when
  build-profile.json5 is missing: use the default SDK version only if
  neither the project config nor the local SDK directory is available,
  and label it clearly as "default, not measured".
- Remove accidentally committed COMMIT_MSG.txt.

Co-Authored-By: AtomCode <jianguo@nutpi.net>
Signed-off-by: 坚果 <jianguo@nutpi.net>

13.2 修订后的推送与解决标记

git add <修订的文件>
git commit -s -m "docs: address review feedback on ..."
git push fork fix/sdk-version-dynamic-read

推送后：

在 PR 页面把已修复的行内评论标记为 Resolved；
如果仍有未解决的讨论，合入会被阻止（这些组织仓库开启了 only_allow_merge_if_all_discussions_are_resolved）；
新增提交会自动触发机器人重新检查（DCO、AI 检视复检）。

14. 阶段十一：测试与合入

14.1 合入条件（全绿才能合）

从案例 PR #45 的合入检查项（mergeable_state）可以总结出完整门槛：

检查项	说明	案例状态
无冲突	base 分支与 head 分支可合并	✅ conflict_passed
分支存在	head 分支存在	✅ branch_missing_passed
MR 状态	非 WIP/Draft	✅ mr_state_passed
讨论全部解决	所有行内评论 resolved	✅ resolve_discussion_passed（开启 only_allow_merge_if_all_discussions_are_resolved）
CI 通过	构建流水线成功	✅ ci_state_passed
审批人通过	至少 N 个审批人 approve	✅ approval_approvers_result: 2/2
测试人通过	至少 N 个测试人 pass	✅ approval_testers_result: 2/2
非自合入	不能自己合自己的 PR（disable_merge_by_self）	✅ merged_by_user_passed

14.2 测试的触发方式（案例实测）

在 PR 评论中由管理员/测试人发送触发指令，openharmony_ci 机器人执行测试并回报结果。案例 PR #45 实测出现过的指令：

指令	效果
`submit`	提交测试
`force_verify`	强制验证
（自动回复）`添加测试通过成功！`	测试通过
（自动回复）`该pr: <url>, 不满足合入条件`	合入条件未满足（需先通过测试等）

测试通过前机器人会明确提示「不满足合入条件」阻止合入；测试通过、条件全绿后才会放行。

14.3 合入方式

组织仓库默认 merge 合入（产生 merge commit，如 !45 merge fix/sdk-version-dynamic-read into main），非 squash；
合入后 Issue 自动关闭（close_related_issue: true，案例 issue #25 在合入时刻自动 closed）；
PR 被自动打上 AI已检视、dco检查成功 等标签，形成完整记录。

15. 合入后收尾

同步本地与 fork 的 main：

git checkout main
git pull origin main        # 拉取合入后的最新 main
git push fork main          # 同步自己的 fork

删除已合入的功能分支（本地 + fork 远端）：

git branch -d fix/sdk-version-dynamic-read
git push fork --delete fix/sdk-version-dynamic-read

核对 Issue 状态：确认配套 Issue 已自动关闭（若未自动关闭，手动关闭并注明合入的 PR 编号）。

16. 案例复盘：PR #45 完整时间线

用真实时间线还原一次完整贡献（2026-09-05 → 2026-09-07）：

时间	动作	说明
09-05 19:08	创建 Issue #25	「建议：HarmonyOS SDK 版本应动态读取…」，中文、模板完整
09-05 19:10	本地提交 `53acc99`	`docs: read HarmonyOS SDK version dynamically instead of hardcoding`（DCO 签名）
09-05 19:11	创建 PR #45	fork `jianguoxu/skills:fix/sdk-version-dynamic-read` → `CPF-Flutter/skills:main`，关联 issue #25
09-05 19:12	`openharmony_ci` 欢迎 + DCO 检查	打上 `dco检查成功` 标签
09-05 19:13	`cpf-manager` 首轮 AI 检视	两个 Skill 评分 B 级，建议合入；附改进建议
09-05 19:26	提交 `6f22f89`	`docs: address review feedback...`，逐条落实评审意见
09-05 19:33	`cpf-manager` 复检报告	指出 COMMIT_MSG.txt 仍误提交，合入建议改为「暂缓合入」
09-05 19:35	行内评论	【一般】COMMIT_MSG.txt 误入仓库，要求删除
09-05 20:11	提交 `14e95ef`	`chore: remove accidentally committed COMMIT_MSG.txt`，清理干净
09-07 09:20	解决讨论	行内评论标记 resolved
09-07 09:21–09:25	测试与验证	管理员评论 `force_verify` / `submit`，`openharmony_ci` 回报「测试通过成功」
09-07 09:25	合入	merge commit `!45 merge fix/sdk-version-dynamic-read into main`，issue #25 自动关闭

经验总结：

先建 Issue 再建 PR，描述要完整（问题/方案/影响范围），评审机器人靠它对账；
commit message 规范：英文、type 前缀、-s DCO 签名、Co-Authored-By；
不要提交临时文件（COMMIT_MSG.txt 教训：一个误提交文件让 PR 从「建议合入」变成「暂缓合入」）；
评审意见逐条回应，修订提交的 message 里列出每条意见的处理；
讨论全部解决 + 测试通过 + 审批通过三者齐备才合入；
合入靠机器人/管理员操作，作者不能自己合自己的 PR。

17. 常见问题与踩坑清单

17.1 提交与推送

问题	处理
推送被拒绝（分支分叉）	fetch 评估分叉；优先推新分支；确认安全才用 `--force-with-lease`，禁用裸 `--force`
误提交临时文件	追加 `chore: remove ...` 提交删除，不要改写历史
DCO 检查失败	检查 `git config user.name/user.email`，用 `git commit -s` 重新提交
commit message 是中文	改为英文一句话 + type 前缀（docs:/feat:/fix:/chore:）

17.2 Issue / PR

问题	处理
PR 未关联 Issue	先建 Issue，再用 `POST /pulls/:number/issues` 关联，body 用 JSON 数组
自动关联了无关的历史 Issue	查询关联列表核对；API 删不掉就去网页端手动移除（自动关联无法 API 删除）
PR body 里写了 Signed-off-by	删除——commit 已有 DCO 签名，PR 描述重复是冗余
curl 内联 JSON 失败	body 含换行/引号，写临时文件用 `curl -d @file`
PR 评论发到 issues 端点	PR 评论必须用 `/pulls/:number/comments` 端点

17.3 评审与合入

问题	处理
AI 检视报告「暂缓合入」	看「⚠️ 需修复的问题」，逐条修复并追加提交，让机器人复检
行内评论标【一般】【建议】	按严重级别逐条回应；修复后在网页端标记 Resolved
机器人提示「不满足合入条件」	检查合入条件清单（冲突/讨论/CI/审批/测试），补齐后再试
想自己合自己的 PR	不行——组织仓库开启 disable_merge_by_self，需管理员/机器人合入

18. 附录：模板与命令速查

18.1 提交命令速查

# 分支
git checkout -b fix/xxx                # 从最新 main 拉分支

# 提交（英文 + type 前缀 + DCO 签名）
git add <files>
git commit -s -m "docs: one-line english summary"

# 推送 fork
git push fork fix/xxx

18.2 Issue body 模板（docs 类，案例所用风格）

## 问题描述

<说明问题/提案背景，逐处列出涉及文件>

## 建议方案

1. <方案1>
2. <方案2>

## 对应修改点

- <文件1>：<改动>
- <文件2>：<改动>

## 影响范围

- <skill/模块1>
- <skill/模块2>

18.3 PR body 模板（skills 仓库风格）

## 概述

对应 issue #N：<一句话说明改动目标>

## 修改内容

| 文件 | 改动 |
|------|------|
| <文件> | <改动> |

## 动机

<为什么改：解决的问题、收益>

## 测试

<测试方式与结论>

DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

大模型是怎么“学会“的：预训练、微调、对齐三段论

大模型是怎么"学会"的：预训练、微调、对齐三段论一、预训练：把世界压缩进参数二、微调：从"会续写"到"会办事"三、对齐：让能力可以被放心使用四、工程与业务视角五、治理：能力之外的责任#世界模型#AGI具身智能#AI技术前沿#Agent大模型。

DAMO开发者矩阵

具身智能研发策略（22）：TVA-World架构的能耗优化与绿色计算

DAMO开发者矩阵

具身智能研发策略（24）：TVA-World架构多模态融合技术新突破

DAMO开发者矩阵

所有评论(0)

查看更多评论

红目香薰

@feng8403000

已为社区贡献22条内容

给 CPF-Flutter / CPF-rn / CJMP 等组织贡献 PR 的完整流程

红目香薰

目录

1. 背景：目标组织与仓库

2. 全流程总览

3. 前置准备

3.1 账号与访问令牌

3.2 git 身份配置（DCO 签名前置）

3.3 提交信息偏好（以仓库规范为准）

4. 阶段一：Fork 与本地环境

4.1 Fork 组织仓库

4.2 本地 clone 并配置双 remote

4.3 保持 main 与上游同步

5. 阶段二：新建功能分支

6. 阶段三：编写提交（commit 规范）

6.1 只提交必要的文件

6.2 撰写 commit message

6.3 案例 PR #45 的三个提交

7. 阶段四：推送到自己的 fork

8. 阶段五：先创建 Issue

8.1 为什么先建 Issue

8.2 Issue 内容（中文）

8.3 用 API 创建 Issue（可选）

9. 阶段六：创建 PR

9.1 页面创建（推荐首选）

9.2 PR 正文结构（案例实际使用的结构）

9.3 用 API 创建 PR（可选）

10. 阶段七：关联 PR 与 Issue

11. 阶段八：触发 CI 构建

12. 阶段九：机器人评审（AI 检视）

12.1 openharmony_ci —— CI / DCO / 测试机器人

12.2 cpf-manager —— AI 评审机器人

13. 阶段十：处理评审意见（修订提交）

13.1 评审意见的回应方式

13.2 修订后的推送与解决标记

14. 阶段十一：测试与合入

14.1 合入条件（全绿才能合）

14.2 测试的触发方式（案例实测）

14.3 合入方式

15. 合入后收尾

16. 案例复盘：PR #45 完整时间线

17. 常见问题与踩坑清单

17.1 提交与推送

17.2 Issue / PR

17.3 评审与合入

18. 附录：模板与命令速查

18.1 提交命令速查

18.2 Issue body 模板（docs 类，案例所用风格）

18.3 PR body 模板（skills 仓库风格）

所有评论(0)

温馨提示：您尚未绑定手机号

红目香薰