前言
這篇文章的起因是朋友的一個疑問：如何參與開源項目？搜尋了一下網上類似的文章，大多都是講解如何操作 GitHub 來給開源項目貢獻代碼、開源協定有哪些以及開源項目的一些介紹。而開源項目作為開源思想的産物，最難的從來都不是貢獻代碼，而參與的方式也不隻有貢獻代碼一種（雖然貢獻代碼是最直接的）。下面就根據我的經驗，介紹一下如何參與到開源項目中。
心理建設
在和不同的小夥伴聊過之後，發現大家都有一個同樣的問題：很多同學都覺得參與開源項目是技術大牛的事情，我們這種技術水準一般的，隻需學習怎麼使用就行了。
那麼這就引出了小标題心理建設的重要性，一個開放的項目（僞開源不算），是可以接納任何可行有益的建議的，隻要是對項目有利的貢獻，都會得到認可（前提是你能說服别人）。會有一些技術大牛維護這些項目，但不代表任何參與該項目人都是技術大牛，就如之前 4 歲小女孩可以給 Linux 核心貢獻送出，隻要你的送出可以提升項目品質，哪怕是一個符号的修改都會得到肯定。社群是開放的，任何人都可以參與進來；社群又是嚴謹的，隻要有錯誤，任何人都可以修改它，并不是“大神”們的專利。
如何開始
開始前，首先要明确你想要做的内容，除了貢獻代碼以外，bug 的發現、新功能的建議、文檔的補充、測試用例的完善，甚至是錯别字的糾正，這些都是參與開源項目的方式。正如上文所說，一個開放的社群，是不會拒絕任何可以提升項目品質的行為的。
而代碼貢獻方面，如果有志于貢獻高品質的代碼、修複 bug 或貢獻新功能，在開始時，可以打開 ISSUE，裡面有一些打着
good first issue
Label 的 ISSUE，這些 ISSUE 通常會使一些小功能的開發或者 bug 的修複，你可以通過完成這個 ISSUE 來踏出你貢獻代碼的第一步。當然，在該 ISSUE 中的交流時必不可少的，這樣可以幫助你更詳細的了解該 ISSUE 要解決的問題，進而在開發中少走彎路。
貢獻規範
每個開源項目都會有自己的貢獻指南（Contributing Guidelines），在參與項目之前，請先閱讀該指南，一般該指南中都會有諸如 Slack channel 或郵件清單這樣的溝通工具的連結，或者釘釘、微信這樣即時交流工具的二維碼（當然最簡單的是在 ISSUE 中交流，并且這也是最直接也最容易得到回複的溝通方式）。
一般來說，不要在 fork 代碼的
master
分支上做任何修改，該分支用來和上遊代碼庫保持同步！ 一個開發分支對應一個功能點，并且對應一個 PR，一個 PR 對應一個 ISSUE，最好不要将多個功能寫在一個 PR 裡，這樣會增加項目維護者 review 的難度。
GitHub 操作
下面就是一些在 Github 上的操作規範。
fork 項目
要參與項目貢獻，首先需要 fork 項目代碼，在項目頁面點選
fork
按鈕，将其 fork 到自己的倉庫中：
本地配置
在項目 fork 好之後，将其拉取到本地：
$ git clone https://github.com/sunny0826/kubernetes.git 為了保持與上遊倉庫代碼一緻，添加上遊倉庫：
$ git remote add upstream https://github.com/kubernetes/kubernetes.git 上遊倉庫添加好之後，之後都可以通過以下指令來使本地倉庫與上遊倉庫保持同步：
# 切換分支
$ git checkout master
# 更新上遊代碼
$ git fetch upstream
# 合并代碼到 master 分支
$ git merge upstream/master
# 上傳代碼
$ git push 建立開發分支
在同步上遊倉庫之後，就可以建立分支，添加自己的修改了：
$ git checkout -b xxx 送出 PR
在開發完成後，就可以 push 代碼，然後送出 PR 了。一般需要在送出 PR 時，将關聯的 ISSUE 标出，并說明該 PR 解決了什麼問題。
而一些大的開源組織會有一些其他要求，比如 CNCF 的項目，在送出 PR 後
k8s-ci-robot會檢測你是否簽署了 Linux 基金會的
貢獻許可協定（如果沒有，就會要求你先簽署一下該協定），同時還會做一些其他操作，比如根據内容打一些标簽、做一些簡單的測試，確定代碼無沖突，并給你配置設定 reviewer（當然也可以使用
/assign
指令自己指定）。
Review
在送出 PR 後，就會有人來對你送出的代碼進行 review。當然，這個人并不會立即出現，因為大部分開源項目的維護者都不是全職的，并且如果該項目的維護者在國外，還需要考慮時差問題。
reviewer 會對你送出的内容進行一些評論，可能是需要更改的點，或者是需要增加一些相關的單元測試，這個過程将一直持續，直到這些内容達到合并的标準，當看到
/lgtm
時，恭喜你，你的代碼通過 review 被合并了。
删除開發分支
PR 被成功合并後，就可以對之前開發的分支進行清理了，因為在 review 中，會送出多個 commit，而合并一般會将這些 commit 壓縮為一個 commit 然後合并到
master
分支，這就導緻了 commit 資訊的不一緻，這也是為什麼在前文要求不要使用
master
分支的原因，如果使用
master
分支，在送出幾次 PR 後，就會多出很多很多的 commit...
清理本地分支：
$ git branch -d xxx 這種方式就是通過分支管理，讓
master
分支始終與上遊倉庫的 commit 資訊一緻，而從
master
分支 checkout 出開發分支，在開發分支内容合并入上遊之後，隻需同步
master
分支内容，然後重複上面的步驟就可以開始新的開發了。
總結
以上就是這些年我參與開源項目的一些經驗，是對網上一些文章的補充，其實不同開源組織的貢獻方式不盡相同，在參與之前一定要先閱讀貢獻指南（Contributing Guidelines），這樣會少走很多彎路。還有就是在 ISSUE 中的交流請盡量使用英語，哪怕你知道和你交流的是一名可以讀懂漢語的人，這樣做的原因是為了讓其他不懂漢語的社群成員可以讀懂你們交流，進而參與進來，而不是讓人以為你們在“密謀”着什麼。