文档/教程【免费下载链接】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 天的内容聚焦开源工作流The Open Source Workflow这一主题以向 Kanister 项目贡献文档为例完整走通Fork → Clone → 修改 → 测试 → Push → 打开 Pull Request → 通过 CI 检查 → 合入上游的全链路。读完本篇你将掌握在 GitHub 上参与任何开源项目的标准贡献姿势并理解本地 Git 命令与远端协作fork、PR、CI如何串联可直接套用到本仓库及其他开源项目中。从 Git 基础走向开源协作在之前的 7 个 Git 章节中我们系统学习了 git 是什么以及 GitHub 这类基于 Git 的服务如何在提供源码仓库托管的同时让更广泛的社区围绕代码与项目协作。前面我们曾通过 GitHub 基础练习完成过fork 一个随机项目并在本地仓库中做修改的过程而今天要更进一步真实地向一个开源项目提交贡献。需要特别强调的是贡献不等于写代码。修复 bug、实现功能特性固然是贡献完善文档同样是贡献本仓库 README.md 中即写明Maybe you can help contribute some resources you have found useful to the project欢迎社区补充资源。每一份微小的贡献都有价值同时它也是把前面学过的 git 功能亲手实践一遍的最好机会——这正是开源工作流的核心思想。第一步Fork 一个项目获取你的项目副本贡献的第一步是找到一个可以贡献的项目。本文的实战案例选择的是Kanister 项目——作者近期正围绕它做技术分享希望把已经发布在 YouTube 上的演讲资源补充进该项目主仓库的 readme.md 文件中。Fork复刻的本质是复制一份完整仓库到你自己的 GitHub 账号下。正如第 40 天内容中总结的fork 让你能自由地实验和修改而不会影响原项目原仓库通过watch获取动态、fork获取副本、star表达认可。操作方式访问目标仓库页面点击右上角的Fork按钮下图红框标注处。Fork 完成后你的账号下就拥有了整个仓库的完整副本。作为参照Kanister 项目 readme.md 中原本只列出了两条演示Presentation资源这正是我们本次要通过贡献流程修复补充的内容——一个典型且低风险的文档类贡献切入点。第二步Clone 到本地机器fork 只是把副本放到了云上的你的账号下真正的编辑还需要把代码拉到本地。操作如下进入你自己 fork 出的仓库页面点击页面上的Code代码按钮获取仓库 URL在希望放置仓库的目录下执行git clone url这里的url就是上一步从 Code 按钮复制的地址。克隆完成后本地就拥有了与你 fork 版本一致的完整工作副本可以开始放心地修改文件。第三步做出你的修改项目已在本地接下来用 VSCode或其他你偏好的 IDE / 文本编辑器打开项目进行修改。本次案例要修改的是readme.md文件它使用 Markdown 语言编写。这里有一个重要的开源协作礼仪当你修改别人的项目时应遵循该项目既有的格式与风格而不是按自己的习惯随意排版。因此作者对照 readme.md 中现有的 Presentation 列表格式将新的 YouTube 演讲资源按同样的结构补充进去。这种跟随上游项目现有格式的做法在文档贡献中尤其重要它直接决定了维护者审阅 PR 时的体验也降低了被要求修改的可能性。第四步测试你的修改文档也要跑一遍作为最佳实践修改之后必须测试。如果是一次应用代码变更我们会确保应用在改动后仍然正常运行同理文档变更也要确认格式正确、渲染效果符合预期。VSCode 可以通过安装扩展获得Markdown 预览能力直接在编辑器中渲染当前文档借助预览你可以即时检查表格、列表、链接、图片引用等 Markdown 元素是否正确显示确保提交给维护者的是一份排版整洁、可读性良好的文档。第五步把修改推送回你的 Fork 仓库由于我们没有直接向 Kanister 上游仓库写入的权限必须走先推送到自己的 fork再向原仓库发起 PR这条标准路线。对修改满意后就轮到那些已经耳熟能详的 git 命令登场了命令链路大致如下提交信息需清晰描述本次改动内容git add . # 将 readme.md 的修改加入暂存区 git commit -m added Kanister presentation/resources # 提交并附上说明性信息 git push # 推送到远端 fork 仓库默认 origin推送完成后回到 GitHub先在自己的 fork 仓库中再次检查这次改动是否符合预期。此时可以在 fork 仓库页面顶部看到一条关键状态提示我们已领先 kanisterio:master 分支 1 个 commit——这正是 git 分支与提交模型在协作场景中的直观体现你的 fork 产生了上游没有的新提交为接下来的 Pull Request 创造了条件。随后点击页面上的Contribute贡献按钮会看到Open Pull Request打开拉取请求选项。第六步打开 Pull RequestPR点击 Open Pull Request 后进入 PR 比较页面这个页面上信息量较大需要逐项理解页面左上角显示当前位于原始/主仓库中页面主体展示的比较对象是原始主仓库base与你的 fork 仓库head可以看到你产生的 1 个 commit若改动较多此处会列出多个 commit下方展示 readme.md 文件的具体变更内容diff供审阅核对。确认变更无误后点击绿色Create Pull Request创建拉取请求按钮。此时需要注意根据项目维护者在其仓库中配置的 PR 模板不同页面可能提供填写指引模板通常会提示维护者希望看到哪些信息。无论有无模板都应撰写一段有意义的描述清晰、简洁但包含足够细节说明你做了什么、为什么这样做。案例中作者填写了简单的变更概述并勾选了 documentation文档类标签。创建完成 PR 后页面会展示该 PR 的摘要信息。第七步自动化检查与 CI 构建向下滚动 PR 页面你会看到自动化流程已经启动。在 Kanister 案例中PR 显示需要评审review required同时一些检查checks正在执行——可以看到Travis CI 正在进行中in progress一个构建Build已经启动。CI 的作用是在任何代码合入之前自动验证你的改动没有破坏任何东西。这里有一个重要的心理建设上图中出现的红色状态看起来有些吓人容易让人以为自己做错了什么。别担心你没有破坏任何东西——这些检查存在的目的正是帮助你与项目维护者。如果确实存在问题根据实践经验维护者通常会主动联系你并给出下一步建议。PR 创建后即对所有人公开可见案例中的 PR 为 kanisterio/kanister 的文档/资源补充。值得注意的是作者在 PR 合并前就将内容发布出来并顺势向仍在跟随挑战的社区抛出了一个趣味练习Fork 本仓库90DaysOfDevOps到你的 GitHub 账号加入你的图片以及可能的文字将改动推送到你的 fork 仓库创建一个作者能看到并批准的 PR完成者可获得一份小奖励。这个小练习完整复用了本天学到的全部流程是非常好的实战训练。结合本仓库90DaysOfDevOps 的官方贡献规范本天讲解的fork → 修改 → 推送 → PR流程正是 CONTRIBUTING.md 中为社区贡献者制定的标准工作流。该文件对本仓库的贡献流程给出了更细化的工程实践可作为开源工作流的补充佐证贡献前通过 discussions 与维护者沟通重要改动建立 issue 并在 PR 中关联确保基于最新的main分支检查已存在/已合并的 PR 避免重复工作提交规范使用 Conventional Commits 风格的清晰提交信息commit message 中关联相关 issue推荐的命令流程对应第五步的 push 环节可推断为在本地终端中执行git remote add upstream 上游仓库地址 # 关联上游仓库 git checkout -b my-new-feature main # 从 main 创建主题分支 git commit -s -a # 带签名提交 git push origin my-new-feature # 推送到 fork 的对应分支与上游保持同步当分支与main脱节时使用git fetch -agit pull --rebase upstream main变基更新再以git push --force-with-lease推送——这也是长生命周期 PR 的常见维护手段更新 PR评审要求修改时可用git commit --amend修改最新提交或用git commit --fixupgit rebase -i --autosquash把新改动压入早期提交随后git push --force-with-lease推送后记得在 PR 中留言提示已更新因为 GitHub 不会对 push 自动发通知。这些规范与 Day 39 中介绍的git diff --staged、git difftool --staged等本地审阅手段一脉相承先本地确认 staged 与 unstaged 的改动git diff --staged查看已暂存变更再提交推送可以显著降低 PR 被要求返工的概率。下一步从开源协作迈向容器至此我们完成了对 Git 与 GitHub 的完整梳理从本地版本控制前 7 个章节到远端托管服务GitHub / GitLab / BitBucket第 40 天再到今天的开源贡献工作流闭环。接下来将进入全新的容器Containers章节以宏观视角探讨为什么需要容器、虚拟化与容器化的关系、我们是如何走到这一步的见第 42 天。如果你想继续深化今天的主题推荐在仓库内探索CONTRIBUTING.md本仓库官方贡献指南包含 fork 流程、PR 规范、分支同步与 squash 技巧README.md仓库主页明确欢迎社区贡献资源第 40 天代码的社交网络GitHub 核心概念fork / star / watch、仓库各功能页签的前置讲解第 39 天查看、取消暂存、丢弃与恢复提交前的本地 diff 审阅与可视化 diff 工具配置。赞分享文档/教程【免费下载链接】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 挑战中文档/教程90DaysOfDevOps Day 41用 Fork Pull Request 走通一次完整的开源贡献流程90DaysOfDevOps Day 41用 Fork Pull Request 走通一次完整的开源贡献流程 本指南基于 90DaysOfDevOps 学文档/教程开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天 在 Git 与 GitHub 基础文档/教程上一篇TPFanControl.ini全配置参考20个关键参数自定义你的ThinkPad风扇控制策略下一篇progress-bar-cj实战避坑性能优化、lpx/px/vp单位换算与常见错误排查清单创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考