向开源项目贡献代码是开发者进阶的必经之路，但复杂的流程往往让人望而却步。特别是面对Flutter-OH这样规范严格的仓库，从DCO签名到PR关联，每一个环节的疏忽都可能导致代码被拒。为了帮助大家避开“无效提交”的坑，顺利拿到开源路上的第一枚勋章，本文将全流程拆解贡献步骤，助你一次通过代码检视，轻松合入主仓。

想要向 Flutter_OH 仓库贡献代码，但不清楚具体合入步骤？别担心！本文整理了从环境准备到代码合入的完整流程，清晰易懂、步骤明确，跟着操作就能顺利完成代码贡献

一、概述

本文详细介绍 Flutter-OH 仓库的代码贡献与合入全流程，涵盖环境配置、协议签署、仓库操作、PR 提交及审核合入等关键环节，适用于所有想要向该仓库贡献代码的开发者。

二、安装 Git

首先需完成 Git 环境配置，为后续仓库操作奠定基础。该步骤可自行参考网上教程完成，确保 Git 能正常使用即可。

三、签署 DCO 协议（必做）

DCO（Developer Certificate of Origin，开发者原创声明），用于声明你提交的代码为本人原创或拥有合法提交权限，是代码合入的前提条件。

📌 签署链接：https://dco.openharmony.cn/sign

操作指引：点击页面「签署 DCO」按钮，使用 AtomGit 账号授权即可完成签署。 > 注意：签署为一次性操作，完成后后续提交无需重复操作。

四、Fork 仓库到个人项目

将 Flutter-OH 公仓 Fork 到个人账号下，后续开发将在个人私仓进行，完成后再发起 PR 合入公仓，避免直接操作公仓。

操作步骤（4 步搞定）

1. 打开 Flutter-OH 目标仓库页面（示例：https://atomgit.com/<org>/<repo>）；
2. 点击页面右上角「Fork」按钮；
3. 选择 Fork 到自己的 AtomGit 账号，点击「确认 Fork」；
4. Fork 完成后，可在个人账号下看到私仓地址：https://atomgit.com/<your-name>/<repo>。

五、Clone 仓库到本地

将 Fork 到个人账号的私仓克隆到本地，便于进行代码开发和修改。

# 使用 SSH 方式克隆（推荐，更安全便捷）
git clone git@atomgit.com:<your-name>/<repo>.git
# 进入项目目录
cd <repo>
# 查看远端配置（确认克隆成功）
git remote -v

补充建议：克隆后默认仅关联个人私仓（origin），建议添加上游仓库（upstream），便于同步公仓最新代码。

# 添加上游仓库（指向Flutter-OH公仓）
git remote add upstream git@atomgit.com:<org>/<repo>.git

六、提交代码到个人仓

本地开发完成后，将代码提交到本地仓库，再推送到个人远端仓，注意需符合 DCO 签署要求。

1. 提交到本地仓库（git commit）

# 提交代码并完成Signed-off-by签名（DCO校验必做）
# 相关疑问可参考：https://atomgit.com/openharmony/docs/blob/master/zh-cn/contribute/FAQ.md
git commit -s -m “feat: 新增 xxx 功能”

⚠️ 注意：

1. 必须添加 -s 参数完成签名，否则无法通过仓库流水线 DCO 检查；

2. 提交信息规范：修复问题以「Fix:」开头，新增特性以「Feat:」开头，清晰描述代码变化。

2. 推送到远端个人仓（git push）

# 推送当前分支到个人Fork仓库（替换分支名为自己的开发分支）
git push origin feature/<your-feature-name>

七、新建 Issue 与 Pull Request（PR）

代码推送至私仓后，需新建 Issue 关联需求/问题，再发起 PR 请求将代码合入 Flutter-OH 公仓，两者缺一不可。

1. 新建 Issue（必做）

Issue 用于反馈 Bug、提出需求或进行讨论，每个 PR 必须关联一个 Issue，建议先建 Issue 再提 PR。

1. 进入Flutter-OH 原始公仓页面（非个人私仓）；
2. 点击页面「Issues」→「新建 Issue」；
3. 选择合适的模板（如 Bug Report、Feature Request）；
4. 填写清晰的标题和详细描述，点击「提交」。

> 重要：记录 Issue 编号（如「#42」），后续 PR 中需关联该编号。

2. 新建 Pull Request（PR）

推送分支后，进入个人私仓页面，GitCode 会自动提示「为此分支创建 Pull Request」，点击即可；若未提示，可手动点击「Pull Request」→「新建 Pull Request」；

1）确认分支对应关系（关键！）：

• 源仓库/分支：个人私仓 <your-name>/<repo> 的 feature/<your-feature-name>；
• 目标仓库/分支：Flutter-OH 公仓 <org>/<repo> 的 main 分支。

2）按照要求填写 PR 信息（参考第八节规范）；

3）点击「创建 Pull Request」，完成 PR 提交。

八、PR 提交规范（加速合入关键）

规范的 PR 提交能减少评审沟通成本，加快合入速度，请严格遵循以下要求：

• 语言规范：代码注释、Commit 信息、PR 标题及描述，均需使用英文；
• Commit 规范：修复问题以「Fix:」开头，新增特性以「Feat:」开头，清晰描述代码变化点；
• PR 描述规范：选择默认 PR 模板，填写完整信息（如关联 Issue、代码修改目的、测试情况等），方便评审人员快速检视。

九、代码检视与审查

PR 提交后，需通过评审和审查环节，确保代码质量符合仓库要求，具体操作如下：

• 代码检视：在 PR 右侧指定评审人员，评审人员会提出检视意见；你处理完所有意见后，@评审人确认，评审人确认无误后点击「已解决」，并通过「代码评审待通过」；
• 代码审查：在 PR 右侧指定审查人员，审查人员会对代码质量、逻辑、风格规范及文档注释进行审核，确认无问题后点击「代码审查通过」；若有问题，需根据意见修改后重新提交。

十、PR 合入要求（必满足）

PR 需满足以下所有条件，方可由 openharmony_ci 自动执行合入，缺一不可：

代码门禁常见错误处理

1. 提示「此 PR 未通过 DCO 校验」：要么未签署 DCO 协议，要么 Commit 未包含 Signed-off-by 信息，按提示指引处理即可；
2. 静态检查 noPass：点击 report 链接查看具体报错，无需解决的报错可@审查人员屏蔽，屏蔽后重新评论「start build」触发门禁；
3. 编译测试失败：点击 build result 链接查看日志，找到失败原因并修复后，重新触发门禁。

温馨提示：若检视、审查环节处理不及时，可在 PR 评论区@对应人员；若仍长时间未响应，可发送邮件至以下地址请求处理： huanglin23@huawei.com、zhuhaojian@huawei-partners.com

按照以上流程操作，就能顺利完成 Flutter_OH 仓库的代码合入啦！如有疑问，可在评论区留言交流~