★ FEATURED ARTICLE 文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本指南基于 90DaysOfDevOps 学习路径中的 Day 41 章节对应 2022/Days/day41.md 及韩语译本 2022/ko/Days/day41.md完整讲解从Fork 项目 → 本地克隆 → 修改文档 → 推送分支 → 提交 Pull Request → 通过 CI 检查 → 成功合并的端到端开源协作工作流。读完本文你将不仅掌握 fork/PR 的标准操作步骤还能理解 base 与 head 分支对比、CI 自动化检查、PR 模板等底层机制并可以直接动手向任意开源仓库提交第一份贡献。从会用 Git 命令到参与开源贡献在 Day 41 之前的 7 个章节里我们已经系统学习了 Git 是什么以及 GitHub 这类基于 Git 的服务如何既提供源码仓库托管又让更广泛的社区围绕代码与项目开展协作。Day 40 已经铺垫了 GitHub 的仓库浏览、Issues、Pull Requests、Actions、Projects 等核心页面并演示过 fork 一个随机项目、在本地仓库中做出修改的过程——2022/Days/day40.md 中用一句话定义了 fork 的本质fork 就是仓库的一份副本fork 之后你可以自由实验改动而不会影响原始项目。Day 41 的目标是把这件事再推进一步真正向一个开源项目提交贡献。需要特别强调的一点是贡献不一定是修 Bug 或写代码功能文档同样是贡献。在 90DaysOfDevOps 仓库中这一点体现得淋漓尽致——2022/目录下同时存在es、ja、ko、pl、pt-br、tr、vi、zh_cn、zh_tw等多个语言译本目录这些正是社区成员以翻译文档这种非代码形式做出的贡献。任何微小的帮助都有意义而且它能让你把前面学过的 Git 功能真正上手用一遍。本次实战的素材是Kanister 项目一个 Kubernetes 应用级数据管理框架作者近期在该项目上做过演讲演讲视频已上传到 YouTube他希望通过贡献流程把新的演讲链接补充进项目主README.md文件中。第一步Fork 项目获得一份属于你的仓库副本整个流程的第一步是找到一个你能够贡献的项目然后Fork它。进入目标仓库页面后点击右上角的 Fork 按钮参见上面的截图仓库为kanisterio/kanister。Fork 完成后你的 GitHub 账户下会立即出现一份整个仓库的完整副本。从截图可以看出MichaelCade/kanister这个新仓库明确标注了它派生自kanisterio/kanister仓库内保留了全部的分支74 个与标签61 个文件目录、提交历史一应俱全。补充一点 Day 40 讲过的细节仓库页顶部有 Watch / Fork / Star 三个按钮含义分别是关注仓库动态、复制一份仓库、认可项目。如果你加入了多个组织fork 时还需要选择把副本放到哪个组织或个人账户下。在继续之前先明确本次要做的改动项目README.md中Presentations一栏目前只列出了两条旧演讲我们要把已发布在 YouTube 上的新演讲链接补充进去。这个场景很小、很典型——正是初学者最适合的第一次贡献形态。第二步把 Fork 克隆到本地fork 是发生在 GitHub 云端的行为真正动手改文件还是要回到本地。在 fork 后的仓库页面点击Code按钮复制 HTTPS 克隆地址然后在希望放置仓库的目录中执行git clone https://github.com/MichaelCade/kanister.git克隆完成后进入仓库目录即可看到README.md、Makefile、Dockerfile.in、build、cmd、docker等全部项目文件当前工作分支为master。至此本地修改的准备工作完成。第三步在本地做出修改并遵循项目既有格式项目已在本地用 VSCode或其他你顺手的 IDE / 文本编辑器打开它开始修改。这里有一个非常关键的协作素养因为你正在修改别人的项目必须遵循该项目既有的内容组织与格式风格而不是按自己的习惯随意排版。README.md文件本身是用 Markdown 语言书写的因此要沿用文件中已有的表格、标题层级、列表风格来插入新的演讲条目。在修改他人项目时先看格式、再动手写是避免 PR 被驳回的最实用技巧之一。第四步测试你的变更——Markdown 预览与差异复核如果修改的是应用程序代码最佳实践自然是跑测试确认功能没被改坏同样地文档修改也要验证格式是否正确地渲染。文档虽然不会运行但格式错误、链接失效一样会破坏阅读体验。在 VSCode 中可以通过安装 Markdown 预览类插件来实时查看文档的渲染效果确认新增条目排版正常、链接可点击。这是文档贡献者最常用也最轻量的测试手段。此外提交之前还建议用之前课程中学到的命令复核变更内容。回顾 2022/Days/day39.mdgit diff --staged可以查看已暂存与未暂存的全部改动git diff对比暂存区与工作区git status则确认当前仓库状态是否干净。在 Day 41 的实操中先git diff检查改动是否符合预期再执行提交能有效避免把错误内容推送给维护者。第五步把变更推送回自己的 Fork 仓库我们没有权限把改动直接 push 到 Kanister 上游仓库这正是 fork 工作流存在的意义——先推送到自己的副本再由副本发起贡献请求。对改动满意后执行这几个已经非常熟悉的 Git 命令git add . git commit -m docs: add presentation link to README git push origin master其中git add .会把目录下所有变更放入暂存区git commit -m记录带说明的提交git push origin master将本地提交推送到你的 fork 仓库——这套基础流程在 2022/Days/day35.md 中已有完整的本地演练。关于提交信息这里可以借鉴 90DaysOfDevOps 仓库自身的 CONTRIBUTING.md 约定该文件明确要求贡献者使用Conventional Commits规范、编写清晰且有意义的提交信息并尽量在提交信息中关联相关的 issue 编号。采用docs: ...这样的前缀不仅让提交历史可读也会让维护者在 review 时更容易理解你的意图。推送完成后回到 GitHub进入自己 fork 的仓库页面复核改动此时顶部会出现一条关键提示This branch is 1 commit ahead of kanisterio:master.——表示你的 fork 分支比上游 master 分支超前 1 个提交这正是待贡献的变更。旁边的Contribute按钮也随之出现点击后会看到Open Pull Request选项。第六步打开 Pull Request——理解 base 与 head 的对比点击 Contribute → Open Pull Request 后会进入 Pull Request 的对比页面这也是整个流程中信息量最大的一个界面左上角显示当前位于原始master仓库即贡献的目标仓库kanisterio/kanister对比的两端分别是base原仓库的master分支即改动要合入的目标与head你的 fork 仓库MichaelCade/kanister的master分支即改动的来源页面显示 Able to merge 状态说明两个分支可以自动合并、无冲突中间列出本次包含的提交数1 个 commit如果改动更多这里会显示多个提交下方展示具体变更文件——本次是README.md右侧 diff 视图可以看到新增的 3 条演讲链接3 行。确认 diff 无误后点击绿色按钮进入下一步。需要理解的是这个对比页面本质上就是请维护者把我的 head 分支合入你的 base 分支的正式申请——GitHub 会自动计算两边的差异、检测是否可合并并展示全部将受影响的行。第七步填写并创建 Pull Request进入创建页面后是否出现 PR 模板取决于项目维护者如何配置仓库的 Pull Request 功能——有的仓库会提供一个带检查清单的模板引导你说明改动类型、测试情况、关联 issue 等有的仓库没有模板需要你自己组织描述。无论有无模板PR 描述都应当清晰、简洁同时包含足够的细节。一份好的描述应说明你做了什么、为什么做、改动涉及哪些文件。原文档的实例中作者填写了一个简单的变更概述并在 PR 类型一栏勾选了Documentation文档类改动——在代码类 PR 中则通常会勾选 Bug fix / Feature 等类型并附上测试结果。填写完毕后点击页面顶部的Create Pull Request即可看到该 PR 的完整摘要页。第八步等待 CI 与审查——读懂那些红色状态创建 PR 后向下滚动页面会看到一系列自动化正在运行。在原文档的实例中可以看到三种典型状态并存Review required需要审查合并至少需要 1 名有写权限的维护者批准Some checks havent completed yet部分检查未完成Travis CI 构建正在运行静态检查已通过Merging is blocked合并被阻止由于尚未获得批准审查合并按钮处于禁用状态。第一眼看到大片红色提示时很容易焦虑仿佛自己犯了什么错误——其实什么都没有被破坏。这是整个开源协作流程中最重要的一课这些检查与门槛机制存在的目的是同时帮助贡献者和项目维护者。CI 构建会在任何东西合并之前验证你的新增内容没有破坏项目如果确实存在问题从作者的实践经验来看维护者通常会主动联系你并建议接下来该怎么做。至此这个 PR 已经对所有人公开可见原实例为 added Kanister presentation/resource #1237。最终PR 合并——贡献闭环的完成在等待合并与 PR 被接受期间原文档还留下了一个面向学习者的开放练习fork 本仓库、添加内容、推送、创建 PR等待维护者审阅。而这一天的内容也以一张成功合并的截图收官——#1237 最终被标记为Merged从MichaelCade/kanister的 master 分支合入kanisterio/kanister的 master 分支两位审阅者通过审查变更统计为 3 行文档内容。回顾整个闭环fork复制仓库→ clone拉到本地→ 修改 → 预览测试 → push推回副本→ 提交 PR申请合并→ CI 检查 → 维护者审查 → 合并。你在第 3539 天学到的git add、git commit、git diff、git status、git log等命令此刻全部派上了用场而在上游仓库更新后保持同步git pull --rebase upstream main、根据 review 意见修改提交git commit --amend、git push --force-with-lease等进阶操作也可以参考 CONTRIBUTING.md 中给出的完整 Contributor Flow 示例。练习把今天的流程自己跑一遍原文档为跟随学习的读者留下了一个实践任务把它完整跑通你就完成了人生第一次开源贡献将 90DaysOfDevOps 仓库 fork 到自己的 GitHub 账户在 fork 中加入自己的图片可附文字说明将变更 push 到你的 fork 仓库创建一个供维护者查看、批准的 Pull Request等待维护者的审阅反馈与合并结果。深入阅读仓库内的相关参考本日英文原版2022/Days/day41.md韩语译本2022/ko/Days/day41.md前一日铺垫GitHub 仓库导航与 Fork 概念2022/Days/day40.mdGit 基础命令演练add / commit / status2022/Days/day35.md差异查看、撤销与 rebase / merge 抉择2022/Days/day39.md本仓库的贡献规范与 Contributor Flowfork、Conventional Commits、与上游同步、更新 PRCONTRIBUTING.md至此90DaysOfDevOps 中关于 Git 与 GitHub 的章节告一段落。接下来的 Day 42 起将进入容器主题从为什么需要容器、容器如何工作的大图景讲起并回顾虚拟化的发展脉络——详见 2022/Days/day42.md。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第41天完整的开源贡献工作流——从 Fork 到 Pull Request90DaysOfDevOps 第41天完整的开源贡献工作流——从 Fork 到 Pull Request 导读 本篇是 90DaysOfDevOps 挑战中文档/教程first-contributions 开源新手实战指南一次走通 Fork 到 Pull Request 的完整贡献流程first contributions 开源新手实战指南一次走通 Fork 到 Pull Request 的完整贡献流程 导读 本文以 first contr文档教程开源治理开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天 在 Git 与 GitHub 基础文档/教程上一篇python-docs-samples 实战Dataflow 最小化自定义容器custom container从镜像构建到作业运行全流程下一篇JavaScript-Load-Image安全指南如何防范XSS攻击和图像注入风险创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
