在 GitHub 上貢獻開源項目的一般步驟
來自： https://github.com/nixzhu/dev-blog/blob/master/2016-02-17-contribute-on-github.md
在 GitHub 上貢獻開源項目的一般步驟
在正確的場合，以正確的方式表達、參與。
作者： @nixzhu
引用：
我并不是 Git 的專家，也不太會用 GitHub。但對于開源項目，如果我在使用其過程中遇到了問題，我會很樂意去其項目代碼托管處（通常是 GitHub）看看有無其他人報告同樣的問題，甚至解決辦法。如果沒有，那我可能會寫一個 Issue。同時，我也會盡我所能去研究遇到的問題，尋找其根源。如果確定能修復此問題，我也會提交一個 Pull Request。
開源項目是很好的學習材料，而且一個好的開源項目在很大程度上可以減少使用它的程序員們的工作，讓他們更專注于自有的業務邏輯。但我們不該止步于此，若能共同維護一個開源項目，讓其越來越好，是一件對所有人都好的事情。
有了參與的主觀意愿還不夠，我們得學會參與的規則和流程。我們以托管在 GitHub 上的開源項目為例。
Issue
假如你使用某個開源項目時遇到了問題，那么你首先應該去其 Issues 頁面看看，例如Yep 的 Issues。除了 Open 的之外，還可以看看 Closed，甚至以可能的關鍵字進行搜索。如果你找到了某個類似的問題，你可以進去留言，說明你所遇問題的情況，或與已有描述的差別。
假如你沒有找到描述類似的問題的 Issue，那么你可以點擊 New Issue 來新建一個。在 Title 里簡明扼要地寫下問題的描述，再在 comment 里詳細描述所遇問題。除了產生問題的條件，如果可能，加上一些自己對問題的推斷甚至可能的解決方案。如果你對問題沒有頭緒，比如代碼在運行中產生了一個死鎖，那么你可以將程序的調用棧貼出來。這些信息有利于項目的維護者定位問題的根源。
寫 Issue 的重要原則就是不要隨意，要將其看成一種參與，一種幫助和自助。因此，詞句要清晰，描述要詳盡。若發完 Issue 后發現還有需要補充的地方，可以進一步增加 comment。
最后，在提交新的 Issue 之前，應該檢查一遍，確保沒有明顯的錯別字和語法錯誤。
Pull Request
我想，有能力的程序員不會止步于發 Issue，他們會更想直接以修正代碼的方式解決問題，這就需要明了 Pull Request 的流程。
簡單來說，Pull Request 是外部開發者參與開源項目的主要方式。因為通常一個開源項目不會允許所有人都去直接修改代碼，這會讓項目變得混亂，難以維護和測試。
因此，外部開發者需要先 Fork 已有項目，然后在自己 Fork 的項目上進行修改，最后這兩個項目就產生了差異，GitHub 可以檢測到這樣的差異。當外部開發者修改完成，就可以利用 GitHub 將自己的改動以 Pull Request 的方式提交到原項目，原項目維護者再對改動進行檢查和測試。在確定沒有問題后，將改動合并到項目中。這樣外部開發者的這一次參與就完成了。
聽起來似乎有些復雜，但正是這樣的流程保證了代碼的持續穩定。因為寫代碼和寫文章一樣，并不是一件隨意的事情。
- Fork。例如在Yep 的項目上，點擊右上角的 Fork 按鈕（請大膽地點擊，這不會對世界造成任何明顯的傷害），然后你就得到了當前 Yep 項目的一個拷貝。
- Clone。因為我們通常在本地電腦上做修改，因此先將 Fork 的項目 Clone 到本地，大家應該很熟悉吧。例如 git clone https://github.com/XXX/Yep.git ，其中 XXX 為你的 GitHub 用戶名。
- 保持同步。大多數學會 Fork 的開發者都會自然地產生一個疑問：如果原項目被改動了，那我們自己的拷貝該怎么同步原項目的改動呢？因為之前的拷貝是以那個時候的原項目為原本的。這也不難，在本地項目中，運行 git remote add upstream https://github.com/CatchChat/Yep.git ，這就將原項目作為了本地項目的上游。你可以在運行此命令之前和之后運行 git remote -v 來觀察改動。之后，若你想同步原項目的改動，執行 git fetch upstream 即可，這會將原項目所有分支的改動都存儲在本地，例如原項目 master 分支會存為 upstream/master ，不過這還不會對本地的項目造成影響。將如你想將上游 master 的改動合并到本地，只需先切換到 master 分支 git checkout master ，再執行合并 git merge upstream/master 即可。同理可以按需要處理 develop 分支等。
如果你的改動很小，那么修改所持續的時間不會很長，你可以不做“保持同步”這一步。當你發出 Pull Request 后，若被維護者合并，你就可以從 GitHub 上刪除你 Fork 的項目了。若下次你還想再修改，完全可以重新 Fork，這一次同樣會以最新的代碼為基礎進行拷貝。
如果你想長期參與，那在做完第三步后，還可以 git branch --set-upstream-to=upstream/master master ，這樣當上游的 master 有改動后，只需在本地 master 分支 git pull 即可。同理，你也可以處理 develop 等分支。
通常，我們都在新分支里做修改，在測試改動沒有問題后才合并到主分支。大家經過總結，出現了一套叫做 Git Flow 的流程。簡單來說，在 master 外，建立一個 develop 分支用于開發，而且，每一個新特性的開發都會從 develop 分支創建新分支，新特性開發完成后再合并到 develop 分支。
我們也并不需要精通 Git Flow，只需記住兩個命令 git flow feature start XXX 和 git flow feature finish XXX ，其中 XXX 是你要開發的特性（或要修復的Bug）的名字。我搜索到一篇很清晰的 關于 Git Flow 的講解 ，大家一起學習。
Yep 的開發使用了 Git Flow，但作為外部開發者，你也不一定非要使用它，因為本質上 Git Flow 也只是建立分支，并以分支為基礎的一套方便工具。
例如 git flow feature start XXX 以 develop 為基礎，創建一個新的 feature/XXX 分支，而 git flow feature finish XXX 就將 feature/XXX 分支合并到 develop，你完全可以直接用 git 命令來實現。例如 git checkout -b XXX develop 就會以 develop 分支新建一個 XXX 分支（這里沒有自動寫上的 feature 前綴），當你完成你的修改后， git checkout develop 然后 git merge --no-ff XXX develop 就可以將 XXX 分支合并進 develop 了。不過，你也可以直接以 XXX 分支發 Pull Request，只需先將其 git push origin XXX 到 GitHub，然后在你 Fork 的項目主頁點擊 Compare & pull request 按鈕即可。如果沒有這個按鈕，也可以點擊 New pull request 按鈕來發起，注意選擇正確的分支即可（你工作的分支到 Yep 的 develop 分支）。
以上是個人對 Git 以及參與 GitHub 項目的粗淺理解，如有錯漏，歡迎以 Issue 或 Pull Request 的方式指正！
歡迎轉載，但請一定注明出處！ https://github.com/nixzhu/dev-blog
歡迎轉發此條
以分享此文或參與討論！