通过提交 PR 完成一次 openEuler 社区贡献
前言
完成 VMware Workstation Pro 25H2 和 openEuler 系统安装后，接下来可以进一步体验 openEuler 社区的真实协作流程。开源社区中的贡献通常不是直接修改官方仓库，而是通过 Pull Request 的方式提交修改，由社区维护者进行审核，审核通过后再合入上游仓库。
Pull Request，简称 PR，是开源社区中非常常见的协作方式。开发者通常会先将官方仓库 Fork 到自己的账号下，在个人仓库中完成修改、测试和提交，然后向官方仓库发起合并请求。社区维护者会对提交内容进行 Review，如果符合社区规范和技术要求，就会将代码合入上游仓库。
本节以 openEuler 社区中的 CoreDNS CVE 修复为例，介绍如何通过 PR 完成一次基础但较完整的社区贡献。整个流程包括部署 Git、Fork 仓库、克隆代码、创建分支、应用补丁、修改 spec 文件、本地构建验证、提交代码、推送分支以及创建 PR。
1 部署 Git 环境
Git 是开源协作中最常用的版本控制工具，用于管理代码修改、提交记录和远程仓库同步。在进行 openEuler 社区贡献前，需要先在 openEuler 虚拟机中安装并配置 Git。
通过 SSH 工具连接 openEuler 虚拟机后，执行以下命令安装 Git：
sudo yum install -y git安装完成后，配置 Git 用户名和邮箱：
git config --global user.name "你的用户名" git config --global user.email "你的邮箱"查看 Git 配置是否生效：
git config --global --list这里的用户名和邮箱会写入后续提交记录中。建议填写与 AtomGit 账号一致的信息，便于社区审核时确认提交者身份。
2 Fork openEuler 目标仓库
本次示例选择的是 openEuler 社区中的 CoreDNS 软件包仓库。CoreDNS 是 Kubernetes 等云原生场景中常见的 DNS 组件，本次贡献的目标是对其进行 CVE 漏洞修复。
首先进入 openEuler 社区对应仓库，例如：
https://atomgit.com/src-openeuler/coredns点击页面右上角的Fork，将官方仓库复制到自己的 AtomGit 账号下。
Fork 完成后，自己的账号中会生成一个同名仓库。后续所有修改都先提交到个人仓库中，再由个人仓库向 openEuler 官方仓库发起 PR。这样既可以避免直接影响官方仓库，也符合开源社区的标准协作流程。
3 克隆个人仓库到本地
进入自己 Fork 后的coredns仓库，点击Clone，复制仓库地址。
然后在 openEuler 虚拟机中执行：
git clone 你的个人仓库地址进入仓库目录：
cd coredns为了后续能够同步官方仓库的最新代码，还需要添加上游仓库地址：
git remote add upstream https://atomgit.com/src-openeuler/coredns.git查看远程仓库配置：
git remote -v正常情况下，origin指向自己的个人仓库，upstream指向 openEuler 官方仓库。
4 创建独立贡献分支
在开源贡献中，不建议直接在主分支上修改代码。更规范的做法是为每一次贡献创建一个独立分支。
本次贡献是修复 CVE 漏洞，因此可以创建一个语义清晰的分支名：
git checkout -b fix-cve-2026-26018查看当前所在分支：
git branch如果当前分支前面显示*，说明已经成功切换到该分支。
在正式修改前，可以先同步上游仓库代码：
git pull upstream master这样可以减少后续提交 PR 时出现冲突的概率。
5 获取并添加 CVE 修复补丁
在 openEuler 的软件包维护中，很多修复不是直接修改源码压缩包，而是通过 patch 文件和 spec 文件进行管理。对于已经在上游项目中修复的问题，可以将上游修复提交导出为 patch，再集成到 openEuler 的 RPM 构建流程中。
以 CoreDNS 的 CVE 修复为例，可以从上游修复提交中获取 patch 文件：
curl -L https://github.com/coredns/coredns/commit/上游修复提交ID.patch -o CVE-2026-26018.patch实际操作时，需要将上游修复提交ID替换为对应漏洞的真实修复提交 ID。
下载完成后，将补丁文件放到当前软件包仓库中，后续还需要在 spec 文件中声明并应用该补丁。
6 修改 spec 文件
openEuler 使用 RPM 包管理机制，软件包的构建规则通常写在.spec文件中。对于 CoreDNS 仓库来说，需要修改coredns.spec文件，让构建系统知道新增了一个 CVE 修复补丁。
打开 spec 文件：
vim coredns.spec首先在 Patch 列表区域新增补丁声明，例如：
Patch9001: CVE-2026-26018.patch然后在%prep阶段应用补丁：
%patch9001 -p1最后在%changelog中补充修改记录，例如：
- Fix CVE-2026-26018这里需要注意，spec 文件的修改要保持格式规范，补丁编号也要避免和已有 Patch 编号冲突。如果仓库中已有类似 CVE 修复记录，可以参考原有写法保持风格一致。
7 本地构建验证
修改完成后，不能直接提交 PR，而是要先在本地验证补丁是否能够正常应用、软件包是否能够正常构建。
可以先执行补丁应用阶段验证：
rpmbuild -bp ~/rpmbuild/SPECS/coredns.spec如果补丁能够正常应用，说明 spec 文件中的 Patch 声明和%patch调用基本正确。
随后执行完整构建：
rpmbuild -ba ~/rpmbuild/SPECS/coredns.spec如果构建过程最终出现类似exit 0的结果，说明 RPM 包构建成功。此时可以认为本地验证基本通过。
如果构建失败，需要根据报错信息检查补丁路径、Patch 编号、spec 文件格式、依赖环境或源码版本是否匹配。
8 提交修改到本地仓库
本地验证通过后，查看当前修改状态：
git status将新增补丁和修改后的 spec 文件添加到暂存区：
git add coredns.spec CVE-2026-26018.patch再次查看状态：
git status确认文件无误后，提交到本地仓库：
git commit -s -m "[CVE] fix CVE-2026-26018"这里的-s参数非常重要，它表示添加开发者签名，即 Signed-off-by 信息。很多开源社区都会要求提交必须带有开发者签名，否则 PR 可能无法通过检查。
提交完成后，可以再次查看状态：
git status如果提示工作区干净，说明本地提交已经完成。
9 推送代码到个人远程仓库
本地提交完成后，需要将当前分支推送到自己的 AtomGit 远程仓库：
git push origin fix-cve-2026-26018推送过程中可能需要输入 AtomGit 用户名和访问令牌。现在很多代码托管平台不再支持直接使用网页登录密码推送代码，需要提前在平台中生成个人访问令牌 Token，并将 Token 作为密码使用。
推送成功后，回到 AtomGit 页面，进入自己的coredns仓库，确认刚才提交的 patch 文件和 spec 文件修改已经同步到远程仓库。
10 创建 Pull Request
确认个人仓库中的修改无误后，就可以向 openEuler 官方仓库发起 Pull Request。
在 AtomGit 页面点击新建 Pull Request，分支选择可以参考如下配置：
源仓库：自己的 coredns 仓库 源分支：fix-cve-2026-26018 目标仓库：src-openeuler/coredns 目标分支：masterPR 标题可以填写：
[CVE] fix CVE-2026-26018PR 描述可以简要说明本次修改内容，例如：
This PR fixes CVE-2026-26018 for coredns by adding the upstream security patch and updating coredns.spec.如果有本地构建验证结果，也可以在 PR 描述中补充说明，例如：
Local build test: rpmbuild -bp passed rpmbuild -ba passed确认源分支、目标分支、标题和描述无误后，点击创建 PR。
11 等待 CI 检查和社区审核
PR 创建完成后，openEuler 社区通常会触发自动化 CI 门禁检查。CI 会检查提交格式、构建结果、依赖变化等内容。
如果 CI 出现失败，不一定代表代码一定有问题。以 Go 语言软件包为例，如果补丁导致依赖项发生变化，CI 可能会提示rpm_provides或rpm_requires有变化。这类情况通常需要结合具体变更进行分析，有时需要社区维护者人工复核。
一般来说，PR 后续会经历以下流程：
系统自动执行 CI 检查；
社区 Committer 对提交内容进行 Review；
如果修改符合要求，Committer 可能会执行
/lgtm；Maintainer 进行最终确认；
审核通过后，PR 被合入 openEuler 官方仓库。
至此，一次通过 PR 参与 openEuler 社区 CVE 修复的流程就基本完成了。
12 小结
通过这次 CoreDNS CVE 修复示例，可以看到 openEuler 社区贡献并不只是简单地上传文件，而是一套完整的工程协作流程。它涉及 Git 分支管理、补丁获取、spec 文件修改、RPM 构建验证、开发者签名、远程推送、PR 创建、CI 检查和社区 Review。
相比单纯完成本地安装，参与一次 CVE 修复更能体现真实开源贡献的价值。即使是初学者，也可以从已有漏洞修复、文档完善、构建问题修复、软件包维护等任务开始，逐步熟悉 openEuler 社区的协作规范，并积累自己的开源贡献记录。