引用：

我並不是 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 的方式提交到原專案，原專案維護者再對改動進行檢查和測試。在確定沒有問題後，將改動合併到專案中。這樣外部開發者的這一次參與就完成了。

聽起來似乎有些複雜，但正是這樣的流程保證了程式碼的持續穩定。因為寫程式碼和寫文章一樣，並不是一件隨意的事情。

1. Fork。例如在 Yep 的專案上，點選右上角的 Fork 按鈕（請大膽地點選，這不會對世界造成任何明顯的傷害），然後你就得到了當前 Yep 專案的一個拷貝。
2. Clone。因為我們通常在本地電腦上做修改，因此先將 Fork 的專案 Clone 到本地，大家應該很熟悉吧。例如 git clone https://github.com/XXX/Yep.git，其中 XXX 為你的 GitHub 使用者名稱。
3. 保持同步。大多數學會 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