Flutter_OH仓库代码合入流程

欢迎大家加入开源鸿蒙跨平台开发者社区：https://openharmonycrossplatform.csdn.net/

想要向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://gitcode.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）

1. 推送分支后，进入个人私仓页面，GitCode会自动提示「为此分支创建 Pull Request」，点击即可；若未提示，可手动点击「Pull Request」→「新建 Pull Request」；
2. 确认分支对应关系（关键！）：
   1. 源仓库/分支：个人私仓 <your-name>/<repo> 的 feature/<your-feature-name>；
   2. 目标仓库/分支：Flutter-OH公仓 <org>/<repo> 的 main 分支。
3. 按照要求填写PR信息（参考第八节规范）；
4. 点击「创建 Pull Request」，完成PR提交。

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

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

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

九、代码检视与审查

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

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

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

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

条件	具体要求
代码门禁通过	在PR评论区输入「start build」触发流水线，需通过DCO检查、编译检查、静态检查，右侧「测试人」显示「已通过」标签
代码评审通过	PR右侧至少指定1名评审人，且评审通过，显示「已通过」标签（点击⚙️可选择评审人）
代码审查通过	PR右侧指定1名审查人，且审查通过，显示「已通过」标签（点击⚙️可选择审查人）
检视意见已解决	PR中所有检视意见均已处理，并点击「已解决」

📌 代码门禁常见错误处理

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仓库的代码合入啦！如有疑问，可在评论区留言交流~