如何在GitHub上協作開發開源項目?
譯文【2013年8月29日 51CTO外電頭條】 也許很多朋友還不太了解,GitHub可以作為一種非常高效的項目開發協作機制。在任何擁有互聯網連接的區域,開發人員都可以隨時與全世界自由共享代碼成果(更不必提強大的工具支持、提交歷史源檢查以及便捷的查看方式)。GitHub已經成為眾多大型開源項目的立足之地,允許來自全球的開發人員共同協作、做出貢獻。
但我們要如何才能加入到項目中來并做出自己的貢獻?當然,相信大家已經了解如何利用Git來追蹤文件變更并將文件推送到服務器端。不過對于大型開源項目而言,GitHub還能帶來其它一些更為顯著的助力,這也使GitHub成為最為理想的項目溫床。在今天的文章中,我們將共同討論開源項目合作過程中的通用規則,并介紹一些大家可能會涉及的知識及靈感。
從小處入手
不要抗拒從小處入手
在著手進行開源項目協作之初,最重要的一點在于正確認識自己的角色定位。通常情況下,很多工作完全可以由我們自己獨立完成而不必勞煩專業技能出眾的編程人員。事實上,害怕自己不足以勝任合格程序員的念頭是影響大部分開發者邁入開源項目領域的最大障礙。不要抗拒從小處入手,先別急著解決什么重大錯誤或者重新編寫整個模塊。最好的起點就是嘗試尋找小型缺陷,例如說明文檔內容缺失或者進行跨設備的檢測及修復工作,甚至連修正簡單的語義錯誤及語法問題也是很有價值的貢獻。
這些較為初級的任務能夠成為大家初步邁入開源貢獻者門檻的良好開端,而且不必擔心碰到自己無法解決的重量級難題。大家可以注冊CodTriage將GitHub問題自動發送至您的個人郵箱。在查看收件箱時,只要感覺有信心搞定當前工作,就請放心大膽地發送接手請求。(我們將在本文稍后位置繼續討論其具體實施過程。)
了解項目的相關生態系統
對于任何協作內容,都可能存在一系列已經被全球開發者所廣泛認可的約定。其中可能包括一套詞匯集、貢獻方式以及提交信息的固定格式,甚至語法標準也已經擁有標準化規范,這就要求每一位貢獻者提前做好了解。在我們嘗試介入某個項目之前,請閱讀與工作相關的全部說明文檔。舉例來說,GitHub提供標準化CONTRIBUTING.md文件(大家可以點擊此處查看jQuery入門指南幫助自己熟悉這一流程)。這些指南文件將由維護代碼庫及主分支的開發人員進行維護。
另一種了解項目生態系統的方式在于查看現有代碼庫以及git日志。通讀開發者提交的信息并認真體會代碼風格能夠幫助大家進一步了解關于項目的方方面面。通過對項目說明文檔的閱讀,我們可以采用更為合作者所熟知的詞匯,從而保證自己的貢獻內容繼續保持同樣的敘述風格。
一旦我們已經成功融入項目的現有文化生態系統,接下來該如何貢獻代碼?
通過pull request工作流進行代碼貢獻
貢獻代碼的工作流程可能令人望而生畏。最重要的一點是要記住按照當前工作項目(正如我們前面所討論過的)的模式及標準處理工作。GitHub所支持的一般性工作流程其實沒那么困難。
1.將目標repo發送到自己的賬戶當中。
2.將repo克隆到自己的本地設備當中。
3.查看新的“主題分支”并做出變更。
4.將主題分支推送回自己的fork。
5.利用GitHub上的差異查看器創建一條pull request。
6.根據請求進行變更。
7.將pull request進行合并(通過在主分支當中),然后將主題分支從上游(目標)repo當中刪除。
在整個工作流程當中,根據給定項目的不同、其具體內容也會出現很多差異。舉例來說,主題分支的命名約定可能有所區別。某些項目使用諸如bug_345這樣的公約,其中345代表已經提交的GitHub問題ID號。某些項目更傾向于提交相對較短的消息。我們將通過以下一系列命令完成前面提到的工作流程。
第一步: 進行Fork
在GitHub.com上對repo進行fork。
第二步: 進行克隆
利用右側邊欄中的URL對repo進行克隆:
- git clone git@github.com:jcutrell/jquery.git
第三步: 添加上游遠程倉庫
切換到克隆目錄,在這里大家可以添加上游遠程倉庫:
- cd jquery
- git remote add upstream git@github.com:jquery/jquery.git
以上命令現在允許大家將本地源中的變更提取出來并加以合并,如下所示:
- git fetch upstream
- git merge upstream/master
步驟四:檢查主題分支
不過在大家執行自己的變更前,請先對主題分支進行檢查:
git checkout -b enhancement_345
步驟五:提交
現在,大家可以執行變更并創建commit以追蹤具體變更內容。
- git commit -am "adding a smileyface to the documentation."
步驟六:推送
接下來,大家將把主題分支推送到自己的項目fork當中。
- git push origin enhancment_345 ‘
第七步:創建pull request
最后,大家需要創建一條pull request。首先,查看repo中的fork,我們可能會看到一條"您最近推送的分支"。如果結果確實如此,則可以選擇"比較并pull request"。如果顯示其它結果,則可以在下拉菜單中選擇自己的分支,隨后單擊repo界面右上角的“pull request”或者“比較”按鈕。
通過“比較并pull request(Compare and Pull Request)”按鈕創建pull request
通過分支下拉菜單創建pull request
兩種方式都會將我們引導至同一個頁面,在這里大家可以創建pull request并在其中添加評論意見。該頁面還以直觀方式顯示出我們所做出的各項變更。這將幫助項目管理員更輕松地查看自己已經完成的工作,同時簡化決策過程、更快決定當前內容是否適合提交。如果變更存在問題,管理員可以在評論中提出質疑;管理員還可以要求我們清空pull request并重新提交,然后關閉pull request。
請注意,向項目管理員表達充分的尊重對于開源貢獻而言非常重要;畢竟我們總是能夠使用代碼的分支版本,如果管理員不打算pull我們的變更,這往往與他們的角色定位有關。請記住,根據GitHub員工Zach Holman在《GitHub如何利用GitHub來創建GitHub》一文中所說,pull request實際屬于對話的過程。最重要的是認同管理員的處理方式;相對于一味要求對方接受我們提交的內容,大家應當調整心態、只把提交過程視為與編寫代碼相關的對話通道。
GitHub Issue+Pull Request=項目管理最佳效果
GitHub提供GitHub Issue,這是一種非常有效的途徑,幫助我們為任何特定項目創建記錄化、交互化以及自動化的bug或者功能對話。不過Issue可以被禁用,而且其在默認狀態下即被禁用。Issue中內置有大量值得稱道的功能,但最重要的功能之一在于其與pull request的整合。用戶只需在提交消息中加入issue的數字ID,即可輕松在所提交信息中羅列該issue作為參考。例如:
- git commit -am "Adding a header; fixes #3"
這條提交消息會在關聯pull request被接受后自動標記3號issue。這類自動化機制使得GitHub成為一款出色的項目開發管理工具。
尋求協作的輔助渠道
通常情況下,大型開源項目會從眾多不同類型的協同工作當中受益。
大家千萬別誤以為開源項目的貢獻途徑就只有通過pull request來實現。通常情況下,大型開源項目會從眾多不同類型的協同工作當中受益。舉例來說,像Ruby on Rails這樣的項目擁有知名度極高的技術社區,該社區會通過論壇及IRC聊天室回答問題,從而幫助開發人員建立起知識框架。這也有助于在討論框架的未來發展方向時迅速從中找到謬誤之處。
這些協作渠道通常作為前面所提到的支持環境開放,例如論壇與聊天室。當然,開發者之間也可以通過電子郵件體系或者電話會議來定義項目的發展方向,共同創建一套活潑而富有成效的項目社區。如果沒有這樣成熟健康的社區體系,pull request的效果將大打折扣。
重中之重在于態度
請記住,開源項目的根本動力來自人們分享知識、建立集體智慧并為之付出努力的態度。要想真正參與到項目中來并做出自己的貢獻,大家應該即使保持一種好奇的態度--“我能幫上什么忙嗎?”--而不應采取較為封閉的態度,例如“我只幫自己想幫的忙”。開源世界中的人們希望與真正樂于幫助他人的開發者一起工作。
總結陳詞
如果大家有興趣參與到開源項目中來,我要首先向您表示敬意!請記住,如果您以正確的態度嘗試接近此類項目、愿意從小處入手逐步積累經驗,那么我們的名字將同自己的代碼一道匯入全球貢獻者的成果當中,并最終服務于世界各地的每一位用戶。請拿出時間與耐心,認真了解與項目及參與者有關的一切知識。如果能在參與項目的同時找到自己的工作興奮點,結果將變得更美好。GitHub的力量以及整個開源世界仍然在一天天不斷壯大;馬上開始與其他開發者們攜手前進,您將順利成為這片新天地中的優秀成員!
原文鏈接:http://net.tutsplus.com/tutorials/tools-and-tips/how-to-collaborate-on-github/