2014年11月28日 星期五

Step by Step 使用github參與專案流程(下)- ISSUE,PR,and CI


        當我們把修改後的檔案push上之後,就可以對原始的來源發PR(Pull Request).但是在發PR之前,先回過頭來說一下要從哪邊開始參與專案.參與專案通常可以分成幾種狀況,一種是自己發起,二是別人發起但是你是主要的參與者,三是周邊的參與者.如果你是前兩種狀況,那麼對於專案本身都會比較了解,知道要開發什麼功能,或是要改什麼東西.但是如果是周邊的參與者,通常不太可能一開始就跳下去做什麼重大的功能開發,而是從一些例如bug或是小功能著手.

        如果不是你自己發現的bug,可以到專案的討論區,也就是ISSUE,看一下有什麼別人提出的問題:
就算自己沒有辦法解決,看一下別人的解決過程其實也是種學習.如果發現自己有機會解決的問題,就會把專案Fork下來改檔案,也才會發生前兩篇文章介紹的行為.

        今天的例子就是我看了一篇別人發的ISSUE,需求寫的很清楚,看起來不會太複雜,就自己跳下來改一下,改完後透過push推到自己的github上後,就可以發篇PR(Pull Request)告訴專案發起人說你針對哪篇ISSUE改了什麼.
上面的畫面是我自己的github,推上來後透過左上角的branch切換到剛剛改的分枝上,下面會註名剛剛我commit了什麼東西上來.如果確認修改的內容沒錯,我們就可以發Pull Request,按一下左上方綠色按鈕:
最上方區塊是只說你要比較的對象以及要發PR給誰(有時候一個專案可能有很多個fork的人,或是很多個分支)右邊的edit可以選擇要比較的對象:
選好之後,下面會列出commit的狀態(跟你要比較的對象之間的版本差異),以及差異的程式碼,讓你再次確認,確認好後就可以按下PR,會進入PR畫面(這邊是跟我自己的master相比):

裡面簡述一下自己的內容,如果輸入`#`字號,可以快速指向某篇ISSUE,自動在PR以及ISSUE之間做連結.確認好後按下Create pull request(在正式發pr前起請再三確認修的內容,說明不要造成專案發起人的困擾).發完後會長得像這樣子(這是我在正式專案上的PR):
一個PR的上方應該要有清楚的標題,說明這篇PR在做的事情,再來github會自動抓說這篇pr來自誰的哪個分流,左邊綠色的OPEN表示專案目前的專案還是Open,還沒結束.我發文留言的下方是剛剛commit的內容(commit的內容也要清楚),右邊紅色的X表示我這個沒有通過CI測試(這個專案有CI測試系統,每丟一個commit都會自動做測試,所以不要亂搞人家...會造成測試機器的負擔),最下方是開發者的回應.之後我又對程式做些修改,修改後只要下commit然後push到github上就會自動連結到PR來,也會自動做測試(因為很重要所以說三次,不要亂下PR,下了之後程式也自己先測試好再commit上來):
上圖表示終於通過了CI測試,這時候開發者也會進一步一起討論後續的問題以及想法.

        小結:要參與專案我想對於git的指令以及操作是必備的技能,現在git+github+CI工具已經讓程式開發流程變得很容易參與,也相當自動化,讓開發者可以更專心在程式開發以及除錯上.除了程式本身之外,參與別人的專案也要注意專案目的,程式功能,以及與專案開發者的相互討論.參與專案不見得都需要高強的實力,專案內容總是有可以貢獻的小地方(找出typo或是修改文件讓文件更易讀)也是貢獻啊~跟不同的開發者討論,合作本身就充滿了樂趣!


沒有留言:

張貼留言