K8s 作為一個開源項目，鼓勵全世界的參與者積極貢獻力量易猫，包括 kubernetes/kubernetes 主項目耻煤、kubernetes/website、kubernetes/enhancements 等 K8s 相關項目都是如此擦囊。本文將介紹給 K8s 提 PR 相關流程违霞、注意事項等。

1. 發(fā)現(xiàn) Bug 先提 Issue

首先恭喜你瞬场，通過認真仔細閱讀 K8s 源碼(https://github.com/kubernetes/kubernetes)买鸽，或在工作實踐中偶然遇到了一個 K8s bug，第一步應該到官方 issues(https://github.com/kubernetes/kubernetes/issues) 下面查詢一下贯被，是否其他人已經(jīng)提過相關或相同的 issue 了眼五，如果沒有查到相關 issue妆艘，那么就可以點擊頁面右上角 "New issue" 創(chuàng)建一個新 issue。

new_issue.png

然后看幼，選擇對應的 issue 類型批旺，如果是 bug 則選擇第一個 "Bug Report"：

bug_report.png

接著，就需要填寫具體 bug 的 title, content诵姜，可以根據(jù)默認模板準確填寫如 What happened, How to reproduce it, Environment(kubectl 版本號汽煮、OS 類型) 等，盡量清晰棚唆、準備描述暇赤，可以直接將 bug對應的代碼文件、行數(shù)標記出來宵凌，方便 Reviewer 快速識別 issue 的真?zhèn)巍?/p>

2. Fork 代碼進行 PR

PR(Pull Request) 第一步是 fork 一份 K8s master 分支代碼到自己的個人倉庫(Repo)鞋囊，在 GitHub 界面上右上角點擊 "Fork"，選擇自己的個人 GitHub 賬號瞎惫，稍等幾秒就可以看到成功 fork 到了自己倉庫溜腐。

此時，就可以在本地通過 git clone 剛剛 fork 的 repo瓜喇，一般默認拉下來是 master 分支挺益，基于 master 分支創(chuàng)建一個新分支，命名清晰達意乘寒。然后就可以愉快的進行代碼更改矩肩，增加相關注釋等，修改完畢 git commit 即可肃续。

注意：commit message 盡量清晰達意，不要使用 @xxx 特殊符號叉袍，末尾不需要加 . 標點符號等始锚。
規(guī)范參見：https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#commit-message-guidelines

3. 提交 PR

在個人分支推送到遠端 GitHub 倉庫后，就可以在頁面發(fā)起 "New pull request"喳逛，選擇個人的更改分支瞧捌，目標分支是 Kubernetes/master，經(jīng)過代碼 "Compare changes" 再次確認本地需要 PR 的文件润文、代碼姐呐，點擊確認。

Tips: Git commit author 一定要與 CLA 協(xié)議(下一步) 一致典蝌，否則 label 將會顯示 cncf-cla: no曙砂，不能通過后面的 merge 校驗。

下一步就是需要填寫本次 PR 相關 title, content骏掀，建議參考 content 模板填寫相關的內容項鸠澈，選擇對應的 sig 小組柱告，release-note 標記等填寫完整，否則可能因為必要信息不完整遲遲得不到 code review笑陈。

pr_content.png

K8s PR 中通過 label 來統(tǒng)一管理流程际度、狀態(tài)變更。

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 協(xié)議

CLA(Contributor License Agreement)：貢獻者同意協(xié)議海渊，這是參與 K8s PR 必須要簽署的一個協(xié)議，分為個人版哲鸳、企業(yè)版臣疑，普通用戶選擇個人版簽訂即可。

如果已經(jīng)簽過 CLA 協(xié)議徙菠，則在 https://github.com/kubernetes/ 項目下面的所有項目都會共享協(xié)議讯沈，即只要在其中任一項目 PR 簽訂了 CLA 協(xié)議，其他項目都是通用的婿奔。

如果是第一次提交 K8s PR缺狠，則會收到機器人推送的簽協(xié)議評論，如下：

cla.png

此時萍摊，就需要根據(jù)鏈接指引挤茄，去 https://identity.linuxfoundation.org/ 簽訂協(xié)議，注冊建議選擇 Log in with GitHub 可以直接獲取到 GitHub username冰木，與上一步 PR git commit author 保持一致穷劈。按提示填寫相關簽約信息后，將收到正式的簽約成功郵件踊沸，如下：

cla_email.png

到這一步歇终，刷新 PR 頁面或等一會查看是否 label 是否變?yōu)榱?cncf-cla: yes，如果等了幾個小時還沒變更逼龟，可以手動評論：/check-cla评凝，將會觸發(fā)機器人重新驗證 CLA 簽約狀態(tài)，并更新 label腺律。

5. Reviewer 反饋

一旦 PR 提交后肥哎，機器人會觸發(fā) label 標記辽俗、CLA 驗證、分配 Reviewer篡诽，針對每個 PR 一般默認分配兩個 Reviewer象浑，對應 Reviewer 將會收到郵件或 Slack 提醒蝠猬，此時就靜靜等待他們來 review 相關代碼改動帘瞭。

此時豪诲，其他 K8s member 也可以主動參與此 PR review，右上角 Reviewers 里面就會看到所有人員达椰，包括機器人默認分配的兩個 Reviewer翰蠢，以及其他主動參與的 Reviewer。

reviewers.png

Reviewer 可以直接在代碼上評論啰劲，也可以在最下面寫評論梁沧，包括一些可以被機器人識別的命令，都是通過 Comment 觸發(fā)的蝇裤，所以需要仔細看 Reviewer 反饋的信息廷支。

6. 跟進 Review

PR 大多數(shù)情況下都不是那么順利就被 merge，title/content 描述可能不詳細栓辜，代碼注釋不合適等恋拍，往往 Reviewer 們會給出很多審閱意見、建議藕甩，或相關 PR 已經(jīng)有其他人提了施敢，也可能會被否定、不被接受等狭莱，此時不要急僵娃，需要根據(jù)反饋意見修改、優(yōu)化 PR腋妙，然后再次提交悯许，此時可以評論 @Reviewer PTAL 再次審閱。

如此反復辉阶，直到 PR 最終被 Merged 或 Closed(未被采納)，時間跨度可能快則幾天瘩扼、一周左右谆甜，滿則幾周、幾個月都有可能集绰，需要及時跟進规辱、提醒 review 進度。

7. 代碼 Squash

Reviewer 審閱覺得代碼改動 ok 了栽燕，此時會看下 git commit 是不是已經(jīng) squash罕袋，如果沒有則一般會評論提醒 Author 進行代碼 Squash改淑。

因為 K8s PR 數(shù)量太多，而每個 PR 對應 git commit 次數(shù)可能很多浴讯，所以 K8s PR 在 merge 之前朵夏，Reviewer 一般會提醒進行代碼 Squash，將本次 PR 所有 git commit 合并為一個 commit榆纽，這樣代碼合并到主分支后仰猖，git log 查看的 git commit 記錄就是一個，大大減小零碎的 commit 數(shù)量奈籽。

git squash 操作如下：

git rebase -i HEAD~3 // 數(shù)字表示要合并的 git commit 數(shù)量

在交互式 editor 中饥侵，將 pick 改為 squash 后保存：

pick 2ebe926 Original commit
squash 31f33e9 Address feedback
pick b0315fe Second unit of work

將會看到：

....
Successfully rebased and updated refs/heads/xxxx

最后執(zhí)行 git push --force 將本地合并后的 commit 強制推送到遠端，即完成了 git squash衣屏。然后就可以再次提醒 Reviewer 進行確認躏升。

8. 終于等到 Approve

經(jīng)過上面的 Review & Squash，終于得到了 Reviewer 的評論 /lgtm, /approve狼忱，恭喜你膨疏，表示此 PR review 通過了，這些評論將觸發(fā)機器人 merge 代碼到主分支藕赞，并標記下一次發(fā)版的 Milestone 如 v1.22成肘。

lgtm.png

在 merge 到主分支之前，機器人會做各種 CI test斧蜕、check双霍，確保全部檢查項都通過，才會真正 merge PR 代碼到主分支批销。

至此洒闸，一個 PR 經(jīng)過以上這些步驟，才最終被 merge 到主分支均芽，PR 狀態(tài)從 Open 變更為 Merged丘逸。相關聯(lián)的 Issues 將會被機器人自動變更為 Closed。

小結

K8s 作為一個開源項目掀宋，鼓勵全世界的參與者積極貢獻力量深纲。本文介紹了一個 K8s PR 的完整流程，主要包括：提 Issue劲妙、Fork 代碼湃鹊、提交 PR、CLA 簽約镣奋、Review 跟進币呵、代碼 Squash 等步驟，如果一切順利侨颈，PR 才可能被 merge 到主分支余赢。

掌握了以上 PR 流程芯义，通過積極參與、貢獻 K8s 項目妻柒，可以獲得從 Author, Contributor, Member, Chair, Lead 的身份轉變扛拨，為 K8s 開源事業(yè)貢獻一份力。

PS: 更多文章請關注公眾號“稻草人生”