前言完成 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 虚拟机后执行以下命令安装 Gitsudo 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 可能会执行/lgtmMaintainer 进行最终确认审核通过后PR 被合入 openEuler 官方仓库。至此一次通过 PR 参与 openEuler 社区 CVE 修复的流程就基本完成了。12 小结通过这次 CoreDNS CVE 修复示例可以看到 openEuler 社区贡献并不只是简单地上传文件而是一套完整的工程协作流程。它涉及 Git 分支管理、补丁获取、spec 文件修改、RPM 构建验证、开发者签名、远程推送、PR 创建、CI 检查和社区 Review。相比单纯完成本地安装参与一次 CVE 修复更能体现真实开源贡献的价值。即使是初学者也可以从已有漏洞修复、文档完善、构建问题修复、软件包维护等任务开始逐步熟悉 openEuler 社区的协作规范并积累自己的开源贡献记录。