文档/教程【免费下载链接】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 天文档2022/zh_cn/Days/day41.md英文原版见 2022/Days/day41.md为核心系统梳理一条完整的开源贡献链路Fork 项目 → 克隆到本地 → 修改与测试 → 推送回 Fork → 发起 Pull Request → 等待 CI 检查与维护者审核。读完本篇你将掌握以“文档贡献”这一低门槛方式参与任意开源项目的完整操作流程并理解 Pull Request 背后的分支对比、CI 自动化与协作规范——这也是本仓库社区内容含多语言翻译版得以持续更新的同款工作流。开源工作流Git 与 GitHub 的社区协作闭环在进入本篇之前第 3440 天已经完成了 Git 核心命令、暂存区管理如git diff --staged、git diff见 2022/zh_cn/Days/day39.md以及 GitHub 平台功能的讲解见 2022/zh_cn/Days/day40.md。Git 负责本地版本控制而 GitHub 这类基于 Git 的服务在此基础上提供了源代码托管与社区协作能力让不同地域、不同背景的人可以共同维护同一份代码。本篇要跨出“在自建仓库里改代码”这一步真正向一个开源项目贡献内容。需要明确的是贡献不等于修 Bug 或写新功能——完善文档同样是高质量贡献。文档改进门槛低、价值直观并且能让你把前面学过的 Git 功能clone、add、commit、push、分支对比完整地实操一遍。事实上本仓库根目录就放置了 CONTRIBUTING.md、CODE_OF_CONDUCT.md 与 Contributors.md社区正是依靠“Fork Pull Request”的方式逐步沉淀出多语言翻译版本2022/zh_cn/README.md、2022/ja/README.md 等。Fork 一个项目获得属于自己的仓库副本贡献的第一步是找到想要参与的项目。第 41 天文档以 Kanister 项目一个 Kubernetes 数据管理工具为例作者近期在讲演 Kanister 相关主题希望把自己已发布到 YouTube 的讲演资料补充进该项目的readme.md中——这是典型的文档型贡献场景。进入目标仓库主页后点击页面右上角的Fork按钮即可在 GitHub 上为该项目创建一份完全属于自己的副本Fork 的含义在 2022/zh_cn/Days/day40.md 中已有说明Fork 是仓库的一份副本允许你自由地实验和修改而不影响原项目如果你隶属于多个组织还需要选择把 Fork 建到哪个账号下。Fork 完成后你会得到一份与上游内容一致、但归属你自己的仓库副本。克隆到本地把 Fork 拉到工作区浏览器里的 Fork 只是托管在 GitHub 上的副本真正的编辑应在本地进行。在 Fork 仓库主页点击Code按钮复制仓库 URL第 40 天演示中使用的是 HTTPS 形式的 URL也可以选择 SSH 方式然后在本地想要放置仓库的目录下执行克隆git clone 仓库URL克隆完成后可以进入目录查看结构cd kanister ls -la这一步把远程 Fork 的完整历史与工作区同步到了本地。从现在开始你可以用自己熟悉的编辑器VSCode、其他 IDE 或任意文本编辑器对文件进行修改修改完成后 Git 会把每一次改动都记录下来。修改文件遵循原项目格式进行编辑拿到本地副本后在 VSCode 中打开项目即可开始编辑。第 41 天文档特别强调了一个专业习惯当你修改的是别人的项目时必须遵循原项目既有的格式与风格而不是按自己的喜好排版。readme.md使用 Markdown 语言编写。在向 Kanister 的 README 中追加讲演资料时需要先观察原文档现有的列表演示格式原文档仅列了两条讲演资源然后以一致的格式追加新条目。这在协作中至关重要格式统一的 PR 能让维护者以最低成本审阅也更容易被合并。测试你的修改文档也要“跑测试”修改代码后需要验证应用仍能正常运行同理文档修改也必须经过“测试”——确认格式正确、渲染效果符合预期。对于 Markdown 文档最直接的方式是使用编辑器的预览能力VSCode 支持安装大量插件其中 Markdown 预览功能可以实时渲染当前文档直观检查标题层级、列表、链接与图片是否正常。补充如果修改的是代码而非文档则应运行项目自身的测试套件或构建命令如go test、npm test等具体以项目文档为准。文档预览 测试通过是提交前最低限度的自检。推送回 Fork把本地提交带回 GitHub我们并没有向 Kanister 上游仓库直接推送的权限因此必须走Fork → 本地修改 → 推送回自己的 Fork这条路线。对修改满意后依次执行已经非常熟悉的 Git 命令git status # 查看工作区与暂存区状态 git add . # 将修改加入暂存区 git commit -m docs: add presentation/resource to readme # 提交 git push # 推送到自己的 Fork 仓库推送完成后回到 GitHub 查看 Fork 仓库的变更可以看到改动已同步到线上且 Fork 仓库顶部出现提示——你比 kanisterio:master 分支领先 1 个提交如果改动分散在多个提交中这里会显示领先多个提交。此时页面上的Contribute按钮会变为可用点击后会出现“Open Pull Request”选项。打开 Pull Request比较分支与提交进入 Pull Request 对比页面后界面信息量较大第 41 天文档逐项拆解了它的组成左上角显示当前处于原始上游仓库比较对象为“上游 master 分支 vs 你的 Fork 分支”即base与compare的对比提交列表本次示例只有 1 个提交如果改动分散这里会列出多个提交文件变更展示你在readme.md中具体改动了哪些行。核对完对比结果后点击绿色按钮进入创建 Pull Request 的流程。这里有一个因项目而异的细节是否出现 PR 模板取决于维护者在仓库中是否配置了 Pull Request 模板。如果项目配置了模板许多项目会在.github/目录下放置模板文件表单会给出提示引导你填写维护者关心的信息无论有无模板都应撰写清晰、简洁、信息充分的描述说明你做了什么、为什么这样做。第 41 天示例中作者写了一段简短的改动概述并勾选了“文档documentation”这一变更类型。创建 Pull Request提交说明与 CI 检查点击Create Pull Request后页面会跳转到 PR 概览页。滚动到页面下方通常会看到自动化检查正在运行示例中的 PR 触发了 Travis CI构建任务正在执行它会校验这次更新是否会破坏现有内容——确保在合并之前不会引入问题。第 41 天文档特意安抚了新贡献者截图中的红色检查项看起来吓人但并不代表你搞坏了什么。CI 失败的常见原因是文档格式细节、链接失效或 lint 规则不满足这些恰恰是自动化在帮你和项目维护者把关。即使真的出现错误维护者通常也会主动联系你并说明下一步如何调整无需过度焦虑。PR 创建成功后即对所有人可见示例中的 PR 为 Kanister 仓库的第 1237 号 Pull Request任何人都可以查看提交内容、参与讨论或留下评论。此后流程进入维护者侧他们可以请求变更request changes、批准approve并最终合并merge。合并前项目维护者还可能要求你同步上游最新改动例如执行git fetch upstream后 rebase这与 Fork 仓库的同步机制相关——这些细节通常会在项目的 CONTRIBUTING.md 中说明。从 PR 到合并给新贡献者的几点提示把整个流程还原为可复用的操作清单在 GitHub 上Fork目标仓库得到自己的副本使用git clone将 Fork 拉到本地在本地按原项目格式修改文件文档或代码通过 Markdown 预览 / 测试命令自检改动用git add、git commit、git push推回自己的 Fork回到 GitHub 点击Contribute → Open Pull Request填写清晰的描述关注 PR 页面上的CI 检查与维护者反馈必要时按意见调整合并完成后可以删除已合并的分支并让本地仓库与上游保持同步。几点经验之谈源于原文档与仓库实践文档贡献同样有价值格式跟随项目、描述写清楚、耐心等待审核是让 PR 顺利合并的三个关键要素。本仓库自身的多语言翻译与勘误内容正是通过社区成员以相同方式提交 PR 沉淀下来的相关协作约定可参见 CONTRIBUTING.md。本章小结与下一步至此Git 与 GitHub 章节收官从本地版本控制、暂存区管理到 GitHub 平台功能与 Fork再到本篇的 Fork → 修改 → 推送 → PR → CI 检查全流程你已经具备参与开源协作的完整能力。下一章将进入容器Containers从宏观视角讨论“为什么需要容器”“虚拟化与容器化的关系”以及容器技术的发展脉络对应文档为 2022/zh_cn/Days/day42.md。相关资料第 41 天原文档整理了一批 Git 与 GitHub 主题的延伸学习资源涵盖 GitLab 完整教程、BitBucket 教程播放列表、版本控制概念、版本控制系统类型、Git 入门/进阶/速成教程以及 Git cheatsheet。该资源列表同时完整收录于本仓库 2022/zh_cn/Days/day40.md 与 2022/Days/day41.md 末尾的 Resources 小节可直接前往查看关于分支对比、暂存与还原等前置命令细节可回看 2022/zh_cn/Days/day39.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 挑战中文档/教程开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天开源贡献工作流实战从 Fork 到 Pull Request 的完整协作路径90DaysOfDevOps 第 41 天 在 Git 与 GitHub 基础文档/教程90DaysOfDevOps 开源贡献工作流实战从 Fork 到 Pull Request 的完整指南Day 4190DaysOfDevOps 开源贡献工作流实战从 Fork 到 Pull Request 的完整指南Day 41 本篇是 90DaysOfDevOps文档/教程上一篇5个理由告诉你为什么Outfit字体是设计师的终极选择下一篇如何在Linux上快速找到文件FSearch文件搜索工具完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考