K8s 作为一个开源我的项目，激励全世界的参与者踊跃贡献力量，包含 kubernetes/kubernetes 主我的项目、kubernetes/website、kubernetes/enhancements 等 K8s 相干我的项目都是如此。本文将介绍给 K8s 提 PR 相干流程、注意事项等。
1. 发现 Bug 先提 Issue
首先祝贺你，通过认真仔细浏览 K8s 源码 (https://github.com/kubernetes/kubernetes)，或在工作实际中偶尔遇到了一个 K8s bug，第一步应该到官网 issues(https://github.com/kubernetes/kubernetes/issues) 上面查问一下，是否其他人曾经提过相干或雷同的 issue 了，如果没有查到相干 issue，那么就能够点击页面右上角 “New issue” 创立一个新 issue。
而后，抉择对应的 issue 类型，如果是 bug 则抉择第一个 “Bug Report“：
接着，就须要填写具体 bug 的 title, content，能够依据默认模板精确填写如 What happened, How to reproduce it, Environment(kubectl 版本号、OS 类型 ) 等，尽量清晰、筹备形容，能够间接将 bug 对应的代码文件、行数标记进去，不便 Reviewer 疾速辨认 issue 的真伪。
2. Fork 代码进行 PR
PR(Pull Request) 第一步是 fork 一份 K8s master 分支代码到本人的集体仓库 (Repo)，在 GitHub 界面上右上角点击 “Fork“，抉择本人的集体 GitHub 账号，稍等几秒就能够看到胜利 fork 到了本人仓库。
此时，就能够在本地通过 git clone 刚刚 fork 的 repo，个别默认拉下来是 master 分支，基于 master 分支创立一个新分支，命名清晰达意。而后就能够欢快的进行代码更改，减少相干正文等，批改结束 git commit 即可。
留神：
commit message尽量清晰达意，不要应用@xxx特殊符号，开端不须要加 . 标点符号等。
标准参见：https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#commit-message-guidelines
3. 提交 PR
在集体分支推送到远端 GitHub 仓库后，就能够在页面发动 “New pull request“，抉择集体的更改分支，指标分支是 Kubernetes/master，通过代码 “Compare changes” 再次确认本地须要 PR 的文件、代码，点击确认。
Tips:
Git commit author肯定要与CLA协定 (下一步) 统一，否则label将会显示cncf-cla: no，不能通过前面的merge校验。
下一步就是须要填写本次 PR 相干 title, content，倡议参考 content 模板填写相干的内容项，抉择对应的 sig 小组，release-note 标记等填写残缺，否则可能因为必要信息不残缺迟迟得不到 code review。
K8s PR中通过label来对立治理流程、状态变更。
PR 提交后，k8s-ci-robot 将会主动新增对应的 label，比方 needs-sig, needs-triage，示意须要确认该 PR 属于哪个 SIG(Special Interest Group)，须要分类等，而后就须要期待相干 K8s members 来 code review，如果确认是此 PR 改变正当, 就会在上面的进行评论如 /sig api-machinery, /triage accepted 等，robot 收到这样的评论后，就会主动将 needs-sig, needs-triage label 去掉，新增评论中对应的 label。
4. 签 CLA 协定
CLA(Contributor License Agreement)：贡献者批准协定，这是参加 K8s PR 必须要签订的一个协定，分为个人版、企业版，普通用户抉择个人版签订即可。
如果曾经签过
CLA协定，则在https://github.com/kubernetes/我的项目上面的所有我的项目都会共享协定，即只有在其中任一我的项目PR签订了CLA协定，其余我的项目都是通用的。
如果是第一次提交 K8s PR，则会收到机器人推送的签协定评论，如下：
此时，就须要依据链接指引，去 https://identity.linuxfoundation.org/ 签订协议，注册倡议抉择 Log in with GitHub 能够间接获取到 GitHub username，与上一步 PR git commit author 保持一致。按提醒填写相干签约信息后，将收到正式的签约胜利邮件，如下：
到这一步，刷新 PR 页面或等一会查看是否 label 是否变为了 cncf-cla: yes，如果等了几个小时还没变更，能够手动评论：/check-cla，将会触发机器人从新验证 CLA 签约状态，并更新 label。
5. Reviewer 反馈
一旦 PR 提交后，机器人会触发 label 标记、CLA 验证、调配 Reviewer，针对每个 PR 个别默认调配两个 Reviewer，对应 Reviewer 将会收到邮件或 Slack 揭示，此时就静静期待他们来 review 相干代码改变。
此时，其余 K8s member 也能够被动参加此 PR review，右上角 Reviewers 外面就会看到所有人员，包含机器人默认调配的两个 Reviewer，以及其余被动参加的 Reviewer。
Reviewer 能够间接在代码上评论，也能够在最上面写评论，包含一些能够被机器人辨认的命令，都是通过 Comment 触发的，所以须要认真看 Reviewer 反馈的信息。
6. 跟进 Review
PR 大多数状况下都不是那么顺利就被 merge，title/content 形容可能不具体，代码正文不适合等，往往 Reviewer 们会给出很多审阅意见、倡议，或相干 PR 曾经有其他人提了，也可能会被否定、不被承受等，此时不要急，须要依据反馈意见批改、优化 PR，而后再次提交，此时能够评论 @Reviewer PTAL 再次审阅。
如此重复，直到 PR 最终被 Merged 或 Closed(未被驳回)，时间跨度可能快则几天、一周左右，满则几周、几个月都有可能，须要及时跟进、揭示 review 进度。
7. 代码 Squash
Reviewer 审阅感觉代码改变 ok 了，此时会看下 git commit 是不是曾经 squash，如果没有则个别会评论揭示 Author 进行代码 Squash。
因为 K8s PR 数量太多，而每个 PR 对应 git commit 次数可能很多，所以 K8s PR 在 merge 之前，Reviewer 个别会揭示进行代码 Squash，将本次 PR 所有 git commit 合并为一个 commit，这样代码合并到主分支后，git log 查看的 git commit 记录就是一个，大大减小系统的 commit 数量。
git squash 操作如下：
git rebase -i HEAD~3 // 数字示意要合并的 git commit 数量 在交互式 editor 中，将 pick 改为 squash 后保留：
pick 2ebe926 Original commit
squash 31f33e9 Address feedback
pick b0315fe Second unit of work将会看到：
....
Successfully rebased and updated refs/heads/xxxx 最初执行 git push --force 将本地合并后的 commit 强制推送到远端，即实现了 git squash。而后就能够再次揭示 Reviewer 进行确认。
8. 终于等到 Approve
通过下面的 Review & Squash，终于失去了 Reviewer 的评论 /lgtm, /approve，祝贺你，示意此 PR review 通过了，这些评论将触发机器人 merge 代码到主分支，并标记下一次发版的 Milestone 如 v1.22。
在
merge到主分支之前，机器人会做各种CI test、check，确保全副查看项都通过，才会真正merge PR代码到主分支。
至此，一个 PR 通过以上这些步骤，才最终被 merge 到主分支，PR 状态从 Open 变更为 Merged。相关联的 Issues 将会被机器人主动变更为 Closed。
小结
K8s 作为一个开源我的项目，激励全世界的参与者踊跃贡献力量。本文介绍了一个 K8s PR 的残缺流程，次要包含：提 Issue、Fork 代码、提交 PR、CLA 签约、Review 跟进、代码 Squash 等步骤，如果一切顺利，PR 才可能被 merge 到主分支。
把握了以上 PR 流程，通过积极参与、奉献 K8s 我的项目，能够取得从 Author, Contributor, Member, Chair, Lead 的身份转变，为 K8s 开源事业奉献一份力。
PS: 更多文章请关注公众号“稻草人生”