Kubernetes 贡献者速查表实战指南面向 community 仓库的 Issue、PR 与本地 Git 工作流【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本文基于 contributors/guide/contributor-cheatsheet/README-hi.mdKubernetes 贡献者速查表编写并参考本仓库 contributors/guide 下的配套文档与源码级说明为你提供一份可以直接上手的TL;DR快速参考。读完本文你将掌握在 Kubernetes 及本 community 仓库中如何快速定位辅助资源、如何在 GitHub 上规范地打开与回应 Issue、如何提交一个符合社区规范的 Pull Request含示例 PR 描述与 Prow 机器人命令、如何签署 CLA以及如何通过 fork-and-pull 分支策略与提交合并squash在本地高效协同。这份速查表面向所有 Kubernetes 贡献者无论你贡献的是代码、文档还是其他形式的成果如本仓库中的 SIG/WG 治理文档、年度报告与流程说明遵循下文的工作流都能让你的 GitHub 贡献体验更顺畅、被合并的概率更高。一、辅助资源贡献前先定位这些入口1. 入门三件套开始贡献之前建议依次阅读以下仓库内文档贡献者指南Contributor Guide讲解如何在 Kubernetes 项目中开始贡献包括欢迎页、前置条件、你的第一次贡献first contribution以及主参考指南是单一事实来源。开发者指南Developer Guide面向直接向 Kubernetes 提交代码的贡献者覆盖开发环境搭建、编码与调试。安全与披露信息报告漏洞以及了解安全发布流程的指南。仓库佐证本仓库根目录的 CONTRIBUTING.md 与 CLA.md 也是新贡献者的必读入口社区成员体系与角色定义见 community-membership.md。2. SIG 与其他团体所有 Special Interest GroupSIG、Working GroupWG、User GroupUG及委员会的完整清单参见仓库根目录的 sig-list.md即Master Group List。该文件由 generator 基于 sigs.yaml 自动生成是判断某个领域归哪个 SIG 管的权威入口。3. 社区沟通渠道日历查看所有 Kubernetes 社区活动SIG/WG 会议、活动等。kubernetes-dev 邮件列表Kubernetes 开发讨论邮件列表。Kubernetes 论坛官方论坛。Slack 频道官方 Kubernetes SlackSlack 使用规范见 communication/slack-guidelines.md。Stack Overflow提出 Kubernetes 终端用户问题的场所。YouTube 频道Kubernetes 社区官方频道含新贡献者研讨会的录制视频。4. 工作流工具Prow 与 TideProwKubernetes 的 CI/CD 系统负责在 PR 上执行测试、打标签、分配审查者。TideProw 的一个组件插件负责管理合并与测试——它通过 GitHub 查询把满足合并条件的 PR 选入tide 池批量测试后自动合并。机器人命令Bot commands用于与 Kubernetes 机器人交互的注释命令常见如/cc、/lgtm、/retest。完整的命令帮助见 contributors/devel/automation.md 所描述的自动化体系。GitHub 标签Labels贯穿整个 Kubernetes 项目使用的标签列表用于分类与 triage Issue 和 PR。Kubernetes Code Search由 dims 维护的代码搜索工具。5. 测试资源Prow同上Kubernetes CI/CD 系统。Test Grid查看历史测试及其关联信息。Triage Dashboard将相似的失败聚合在一起便于集中排查问题。深入阅读本地与 CI 测试的具体方法见 contributors/devel/sig-testing/testing.mdIssue triage 的分步流程见 contributors/guide/issue-triage.md。6. 重要邮箱别名Email Aliases邮箱用途communitykubernetes.io就社区问题联系社区团队SIG Contributor Experienceconductkubernetes.io联系行为准则委员会私有邮件列表githubkubernetes.io私下联系 GitHub 管理团队涉及敏感事项团队介绍见 github-managementsteeringkubernetes.io联系指导委员会公开地址带公开存档steering-privatekubernetes.io私下联系指导委员会敏感事项socialcncf.io联系 CNCF 社交团队博客、Twitter 账号及其他社交资产7. 其他实用链接开发者统计Developer Statistics查看所有 CNCF 托管项目的开发者统计信息。二、在 GitHub 上有效沟通1. 对彼此保持卓越Be Excellent to Each Other第一步请先熟悉仓库根目录的行为准则Code of Conduct以及体现社区价值取向的 values.md。2. 好 / 坏沟通示例提 Issue 或寻求帮助时请保持礼貌 当我在做 Y 时 X 无法编译你有什么建议吗 X 不工作请修好它关闭 PR 时给出有解释性且友善的留言说明为何不满足合并要求 我将关闭这个 PR因为这个功能无法支持用例 X。按其当前提议的形式用工具 Y 实现会更好。感谢你为此付出的工作。 这为什么没有遵循 API 约定这应该在其他地方做沟通风格的完整约定还可参考 contributors/guide/style-guide.md 与评审指南 contributors/guide/review-guidelines.md。三、提交贡献从 CLA 到合并的完整流程1. 签署 CLAContributor License Agreement在提交任何贡献之前你必须签署贡献者许可协议CLA。Kubernetes 项目只接受你或你的公司已签署 CLA 的贡献。如果签署过程中遇到问题请遵循 CLA 故障排查指南。新贡献者也可以先在 contributor-playground 仓库中练习提交第一个 PR其说明同样以 CLA 签署为先决条件见 contributors/guide/README.md 的 Prerequisites 章节。机制说明在第一次提交时机器人会自动检查 CLA 状态PR 若被标记为cncf-cla: no则不会被标记为可测试ok-to-test详见下文。2. 打开与回应 IssueGitHub Issue 是追踪 Bug 报告、增强请求、失败测试等问题的主要手段。但它们不用于用户支持请求。支持类问题请先查看故障排查指南或到 Stack Overflow / Kubernetes 论坛提问。参考资料标签体系Labels、Prow 命令commands。创建 Issue 的要点有模板时务必使用 Issue 模板并遵循模板内的指引——正确模板能帮助其他贡献者更高效地回应你。描述要有信息量descriptive。分配合适的标签。如果不确定k8s-ci-robot 机器人会自动回复你这个问题有效 triage 所需的标签。使用 [/assign username] 或 [/cc username] 分配 Issue 时要克制——比起给 Issue 挂更多人打上正确标签才能让 triage 更高效。回应 Issue 的要点当你着手处理某个 Issue 时先在 Issue 上留言让大家知道你在处理避免重复劳动。当你日后自行解决了某个问题时在关闭 Issue 前留言说明。引用相关的其他 PR 或 Issue或任何可访问的材料例如ref: #1234——这有助于表明相关工作已在别处得到处理。3. 打开 Pull RequestPull RequestPR是向 git 仓库贡献代码、文档或其他形式工作的主要手段。本仓库的各类 SIG/WG 文档如各 SIG 目录下的 annual-report-*.md、charter.md正是通过 PR 流程维护的。参考资料标签、Prow 命令、PR 流程、GitHub 工作流。创建 PR 的要点有 PR 模板时遵循其指引。如果是琐碎修复如坏链接、拼写、语法错误请顺带审查整个文档是否还有其他潜在错误不要为同一文档中的小修复开多个 PR。在 PR 中引用与其相关的 Issue包括该 PR 可能解决的 Issue。避免在单个 commit 中塞入过大的变更把 PR 拆成多个小的、逻辑清晰的 commit便于评审。在你自己认为需要进一步说明的地方给 PR 加注释。用 [/assign username] 分配 PR 时要克制——分配过多审查者并不会让 PR 更快得到评审。如果 PR 属于进行中work in progress在标题加[WIP]前缀或使用 [/hold] 命令防止在[WIP]或 hold 解除前被合并。如果 PR 迟迟无人评审不要关闭再用相同改动开新 PR而应在评论中用github username提醒审查者。如果 PR 得不到足够关注可把 PR 链接贴到 Slack 的#pr-reviews频道寻找更多审查者。深度补充来自 contributors/guide/pull-requests.md无人认领的 PR 超过 90 天会被关闭/hold与[WIP]会分别触发do-not-merge/hold与do-not-merge/work-in-progress标签来自非组织成员的 PR 需要组织成员评论/ok-to-test才会运行预提交测试ok-to-test同时意味着审查者确认该 PR 不会浪费 CI/CD 资源、不存在恶意代码风险。4. 示例 PR 描述及其解读Ref. #3064 #3097 All files owned by SIG testing were moved from /devel to the new folder /devel/sig-testing. /sig contributor-experience /cc stakeholder1 stakeholder2 /kind cleanup /area developer-guide /assign approver1 approver2 approver3这个 PR 里有什么第 1 行— 引用其他 Issue 或 PR#3064 #3097。第 2 行— 简要描述 PR 做了什么。第 4 行— 通过命令/sig contributor-experience将 PR 分配给某个 SIGSIG 分配。第 5 行— 通过 [/cc] 命令指定可能对这个 Issue 或 PR 感兴趣的审查者。第 6 行— [/kind cleanup] 命令添加一个标签将 Issue 或 PR 归类为与清理代码、流程或技术债相关。第 7 行— [/area developer-guide] 命令将 Issue 或 PR 归类为与开发者指南相关。第 8 行— [/assign] 命令为 PR 分配一个批准者approver。批准者由 k8s-ci-robot 根据 OWNERS 文件中的所有者列表推荐评审通过后他们会为 PR 添加 [/approve] 标签。机制说明见 contributors/guide/owners.mdKubernetes 采用reviewer approver两阶段评审机制。OWNERS 文件以 YAML 格式声明reviewers可以/lgtm的候选人与approvers可以/approve的人机器人Prow 的 repoowners 组件据此自动分配审查者、建议批准者。5. PR 故障排查TroubleshootingPR 提交后Kubernetes CI 平台 Prow 会执行一系列测试。若有测试失败k8s-ci-robot 会在 PR 上回复失败测试与可用日志的链接。向 PR 推送新 commit 会自动重新触发测试。偶尔 CI 平台本身会出现问题——即使你的贡献通过了所有本地测试也可能因多种原因失败。此时可用/retest命令重新运行测试。关于特定测试的故障排查细节参见测试指南。本地预检建议来自 contributors/guide/pull-requests.md提交 PR 前可运行make verify、make test、make test-integration来预测 CI 通过与否。6. 标签体系LabelsKubernetes 使用标签对 Issue 和 PR 进行分类与 triage。打对标签能让你的 Issue 或 PR 被更高效地处理。参考资料标签列表、Prow 命令。常用标签命令[/sig sig name] — 为 Issue 或 PR 的归属分配一个 SIG。[/area area name] — 将 Issue 或 PR 关联到特定领域area。[/kind category] — 对 Issue 或 PR 进行分类如cleanup、bug、feature。四、本地工作分支策略与提交整理在你提出 PR 之前必然需要在本地做一些工作。如果你是 git 新手Atlassian git 教程是不错的起点斯坦福的 Git magic 教程则是很好的多语言选择。参考资料GitHub 工作流、本地测试、开发者指南。1. Fork and Pull 工作流Kubernetes 项目采用 GitHub 标准的fork-and-pull工作流你的个人 fork 称为origin项目真实的 git 仓库称为upstream。要让个人分支origin与项目upstream保持同步必须在本地工作副本中配置好这两个远程。完整的分步说明含在云端 fork、克隆到本地、创建工作分支等见 contributors/guide/github-workflow.md 的 1~7 步流程。2. 添加 upstream 远程把upstream添加为远程并配置为不能向其推送# 将 upstream git repo 替换为上游仓库 URL # 例如 # https://github.com/kubernetes/kubernetes.git # gitgithub.com:kubernetes/kubernetes.git git remote add upstream upstream git repo git remote set-url --push upstream no_push运行git remote -v可以验证配置它会列出你配置的所有远程。3. 保持 Fork 同步从upstream拉取全部变更并在本地master分支上执行 rebase即可让本地仓库与上游项目同步随后推送到远端mastergit fetch upstream git checkout master git rebase upstream/master git push在创建新分支做功能或修复之前至少要执行一次上述同步git checkout -b myfeature注意来自 contributors/guide/github-workflow.md同步时请使用fetchrebase而非git pull——git pull会执行 merge 并产生合并提交污染提交历史。4. 合并提交Squashing Commits合并提交的主要目的是生成一份干净、可读的 git 历史/变更日志通常在 PR 修订的最后阶段进行。如果你不确定是否该 squash宁可保留更多提交把决定权留给负责评审和批准你 PR 的贡献者。执行交互式 rebase选择保留哪些提交、合并哪些提交然后强制推送分支git rebase -i HEAD~3 ... git push --force补充说明来自 contributors/guide/github-workflow.md在交互式 rebase 中把pick改为squash即可将某个提交合并进前一个提交fixup则丢弃被合并提交的日志信息。强制推送建议使用git push --force-with-lease更安全。也可用机器人辅助在 PR 上评论/label tide/merge-method-squash由 Tide 在合并时自动将所有提交合并为一个但这会由 GitHub 生成合并消息且不利于你把一个大型 PR 拆分为多个逻辑独立的提交。5. 合并后的工作流评审者reviewer打出/lgtm、批准者approver打出/approve且所有测试通过后PR 进入 Tide 管理的合并池。Tide 会批量选取满足条件的 PR 进行最终合并确保不会有其他 PR 引入不兼容的变更详见 contributors/guide/pull-requests.md 的 Testing and Merge Workflow 章节。五、总结一次贡献的完整路径阅读贡献者指南与行为准则签署 CLA。通过 sig-list.md 找到相关的 SIG在 Issue 中确认你的想法是否被需要重大变更还需走 KEP 流程。在本地按 fork-and-pull 工作流配置origin/upstream创建功能分支myfeature。用规范的 Issue/PR 模板打开 Issue通过/sig、/area、/kind命令打上正确标签用/cc、/assign指定审查者。提交 PR 后等待 Prow CI 测试失败时用/retest重跑按评审意见在myfeature分支上迭代。评审通过/lgtm/approve后按需 squash 提交手动 rebase 或/label tide/merge-method-squash等待 Tide 自动合并。掌握这套速查表你就具备了在 Kubernetes community 生态包括本仓库的 SIG/WG 文档维护中高效贡献的完整技能栈。若需要进一步查阅仓库内配套文档PR 流程、GitHub 工作流、Issue triage、OWNERS 机制、测试指南可提供更深入的细节。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考