[心得分享] 我在 GitHub 上學習開源

先祝給位聖誕節快樂！

文章拖了將近一年的時間，我想是時候能夠把兩年多在 GitHub 開源的經驗分享給你們，雖然不及神人級的開發者，但我始終相信，分享、自由、開放、討論和開發者是開源的核心精神。

若是你不知道什麼是 GitHub，但多少應該也知道 Bitbucket, CodePlex, Google Code, GitCafe 等等，就先假設你們都知道吧～

先說聲抱歉，也許用詞上你們可能不太習慣，再請你們提出修正並給予建議。

文長，對着電腦的各位，進入正題前，泡一泡咖啡提提神！

[ 接觸 GitHub ]

N 年前聽教授介紹開源有多厲害，國外高手都是怎麼玩開源項目的，就從那個時候開始，接觸了 GitHub。除了 GitHub 你還能夠選擇國產 GitCafe，用過 GitHub 都應該能夠感覺到，大衆仍是較爲喜歡 GitHub，不管是 UI/UX、效率仍是社羣，GitHub 仍是擁有極大的優點。

開始的時候玩一玩就立立刻手，根本就是快快樂樂學 Git/GitHub，透過 GitHub 才慢慢了解 Git。一開始使用 GitHub 提供的 GitHub Desktop 來 commit push，但後來好像 bug 不少，這時就開始接觸 command line (cmd)，就一直用到如今，如今已經回不去 GUI 了。

有付費買過 GitHub 私人空間的人和公司其實很多，但費用也不便宜。還記得以前在公司直接用 GitHub Importer 把整個公司項目複製一份到 GitHub 上，不費吹灰之力就完成了，若是你的項目是 svn，轉換過去 git 也是沒有問題的！

[ 前輩 ]

兩年前本身很嫩（如今仍是很嫩），前輩開始教我多學習別人的開源項目、學習模仿等等的，到如今我仍是恨感激這位前輩，沒有他推我一把，我可能就沒繼續開源下去了。看了幾個星期後，前輩讓我開一個項目，恰好公司網站是使用 AngularJS 當前端架構開發，那就寫一個前端驗證工具吧。定義需求、規則、功能，再來定義最重要的 SPEC，接着開始寫主要模組，其中固然少不了被前輩叮說這怎麼這樣寫等等之類的。

我還記得很清楚，前輩說：那開始寫測試吧，寫測試的時間是寫模組的兩倍時間哦！問題是，我怎麼知道該如何寫測試，並且是該死的 AngularJS，哪懂什麼 protractor，由一堆什麼 BDD/TDD, JUnit, QUnit, Jasmine, Mocha 的。就直接模仿了前輩的程式，也終於把完整的測試給寫出來了。從開始到結束大約花了3個月的時間，前輩也已經離職了。大體初步功能也完成了，DEMO 頁面也寫好了，就立馬開源，這裏簡稱 A-V！

不要懷疑，前輩是個牛人，因此我很是的辛運！

[ N4J ]

其實在 A-V 出來以前，我只會 jQuery，正在學習 jQuery 寫第三方套件的時候開發了 N4J 的前端工具，N4J 是純粹學習用的，學習如何使用 GitHub、結構以及書寫文件。還記得本身寫得很開心，多年回去看還記得那時候的興奮，後來畢業後也用 N4J 順利拿到了聘書，畢業後就立刻就業。

[ A-V ]

先說說 A-V 目前的情況，有 2xx commits、1x releases、2x contributors，比起大型項目這個數字沒什麼，但對我來講，這些數字都是一個確定，一個成就，我想這是開源帶給個人好處之一，也是讓我持續投入時間的緣由。

完成第一個版本後就立刻上線了，寫過程式的人都知道，這時候就會出現上線臭蟲，版本 1.0.5, 1.0.6, 1.1.0 後，纔開始慢慢穩定下來。

很快的，我試着在各論壇發表本身的做品，也包括中國的一些社羣，分享本身這幾個月下來的成果，但很惋惜迴應個人人沒有不少，也許是做品沒有爆炸性，畢竟只是個前端驗證工具。其實難免有點小小的失望，沒有人討論，沒有任何回饋。但有一點值得注意的是，AngularJS 在這方面尚未太多相關的套件和討論，因此我算是進入了對的時間點。

幾個月下來，我持續開發、增長功能、把程式寫得更好，來了第一個 issue，後來也陸續來了幾個，應該是我以前在某個論壇發文，有人看到進來給我意見。固然我就當即回覆謝謝他們的提議，立刻修改或者問說有什麼建議等等之類的。由於有人看到，star 了事後就會更多人看到，甚至有人開始丟 PR 給我，在這裏我學到，有人丟 PR 給你，你必定要接受，除非他的程式充滿問題，但也不能立刻拒絕，要提出本身的理由決定是否要對方修改仍是繼續討論下去。其實我在別人的開源項目也是如此，丟了一個 PR，幾天內沒有人回覆會以爲很傷心，但一旦被接受或者回覆，心理會很開心，太棒了，被接受了！這是一種被確定，支持的動做。因此只要有人丟 PR 我大部分都會接受。

接下來的幾個月，更多的 issue 更多的 PR，一我的沒法承擔全部的問題，因此不少我回覆後就沒有繼續了，一旦有時間多是一個月後，纔有時間回來看到底發生什麼問題，就這樣慢慢把 bug 修復。還記得有一次，有個 issue 幾個月下來都解不了，某天晚上到了咖啡廳坐下，瞬間就解掉了，這必定要上一個新標籤說 「fix feature or major improvement」，其實這是開發開源的小確幸，只有你知道發生了什麼事，即便你公告了你修復這個功能，會理你的人沒有多少。

中間固然有停下的時候，徹底沒有任何聲音本身也沒動力繼續開發解 bug，但忽然有人丟了一個 bug 或者 PR 事後，又會瞬間熱血起來，不修掉不行的那種感受，修掉後會很開心，而後又會安靜一陣子。大概就是這樣來來回回的情況。

固然若是你的項目是那種爆炸性的，好比說 pageres、express、awesome，不會是以上的故事

前幾個月，由於自覺 A-V 掉入了谷底，好久沒有更新也沒有人問說進度，開了一個 issue 「Looking for Collaborators」，自覺得會有人挺身而出的說：「我來」，結果一個都沒有。在這裏我學習到的是，開源項目，就是要讓他慢慢的醞釀，果真某一天有人丟了個PR 幾乎大改了我整個架構，改着改着他的興趣就來了，我就問他說要不要當 Collaborator，他也就立刻說好。後來咱們也開了個Slack 羣組，討論著 A-V 的開發。也許有人以爲這沒什麼，可是這種與網友一塊兒奮鬥，討論著彼此的專業，這份經歷是工做永遠沒法取代的。

以上故事就是不停的 loop，持續了兩年，直到如今不是一我的在開發修 bug，而是有同伴一塊兒討論，彼此給意見，這就是開源的魅力所在。

A-V 事後，陸陸續續展開對開源的興趣，看了不少知識產權的選擇（仍是以爲迷迷糊糊的），期間也開了很多的項目，像是 IG、GE、SSS、JSD 等等的，雖然沒有像 A-V 那麼精彩，但不免仍是有issue 有 PR（真的很珍貴）。

[ A-J ]

A-J 雖然不是我開始的，是我主動寄信給做者要求成爲 Collaborator。A-J 屬於爆炸性的項目，如今已經有四位數的星星，一般這類型的項目 issue 和 pr 會多到你接到手軟會想吐，大概會忽略他一陣子，而後一段時間後再來慢慢處理。可是既然是本身主動要求幫忙的，就有責任繼續維護它，開源要學習的其中一點就是－主動，包括提出問題、意見、結果、拒絕，你的任何一個動做都在幫助一個開源項目的進步，這裏就真的是責任制了。每一個項目都有本身的步調，你也能夠不要主動，讓原開發者自行決定項目方向。

[ Gitter ]

其實我以爲 GitHub 提供的 Issue 已經很好用了，整個項目的討論都能在 Issue Comment 完成，有必要還能互相關聯，甚至下標籤來整理 Issue 分類。但有時候不是全部人都喜歡在 Issue 問問題，也有可能擔憂問到重複的問題。

若是你的項目很大，你能夠建議你們到 stackoverflow/segmentfault/irc 尋找問題，但對於比較小的項目，可使用Gitter。 Gitter 是一個聊天室，會自動整合 GitHub，任何的動向都會紀錄在 Gitter 內，讓全部人進入一個獨立的空間討論問題。多一個管道讓你們凝聚，其實多少也能幫助到你，由於一個聊天室裏面，你們都能發言，你不回答其餘人會幫你回答的。

[ 已死? ]

經常逛 GitHub，你會發現有不少有趣的項目，但看到最新的更新時間，什麼！是一年前。這時候就會開始腦補，是否是項目已經沒有在開發了，做者彷佛也消失了，有好多 issue 好多 PR 都沒有被接受。本身也嘗試丟了 issue 詢問項目開發進度，固然也沒獲得任何迴應。偶爾仍是會以爲很惋惜，這麼棒的一個項目是否是被拋棄了。

可是不要氣餒，就由於這是開源，這是一個開放的社羣，任何人都有權利查看修改更新（有的是不容許的），先查查看 fork 分支，有時候分支的星星數還會比本來的還要多，再看看 issue 裏面有沒有人在討論替代方案。最後一招就是本身 fork 本身改，固然你也能夠開一個全新的項目來作同樣的事情。

[ END ]

以上是我在 GitHub 上學習開源的經驗分享。對我來講，滑 GitHub 已經成為我生活中的一部分。打開 GitHub 點擊 Explore 經常會有意想不到的新項目，也是吸取新知識、新趨勢的好地方。

有人說，維護開源項目，就像是開一間公司，你要不停的對他持續開發，對的時機對的功能，持續研究並找尋突破點，公司才能活得久。

原諒我把開源項目的名字都縮寫了，由於這不能是個廣告文，但
不瞞各位，我就是來騙讚的啦，騙星星爲其次，再來騙 followers，但我必定會持續開源，增長本身的能力。

不知道你們的開源經驗是什麼呢？