如何使用GitHub

原文連接：https://medium.freecodecamp.org/a-developers-introduction-to-github-1034fa55c0db

編譯：https://mp.weixin.qq.com/s/ETtYLAMzl_C5SsO2-CZ06w

GitHub是一個擁有數十億行代碼的網站，天天有數百萬開發者彙集在一塊兒，與開源軟件進行協做和報告問題。簡而言之，它是一個基於Git構建的軟件開發人員的平臺。
做爲開發人員，你幾乎天天都要在工做中使用GitHub或其餘基於Git的工具。用於託管代碼或協做其餘人的代碼。這篇文章解釋了GitHub的一些相關概念，以及如何它的一些功能使用來提升你的工做效率。
爲何選擇GitHub？
如今你已經知道GitHub的用途了，但你可能會問爲何我要使用GitHub呢？
畢竟，GitHub由一傢俬人公司管理，並且還會經過託管人員代碼獲利。那麼爲何你還選擇使用它而不是選擇像BitBucket或GitLab這樣相似的平臺呢？
除我的偏好和技術緣由外，還有一個重要緣由：每一個人都在使用GitHub，所以網絡效應很是大。
主要的代碼庫已經隨着時間的推移從其餘版本控制系統遷移到Git，由於更加便捷，而且GitHub定位十分明確，並投入了大量的努力來知足開源社區的需求。
因此今天，你要查找的軟件庫基本上99%能夠在GitHub上找到它。由於平臺十分便捷，除了開源代碼以外，許多開發人員還會在GitHub上託管私有存儲庫。
下面，咱們開始瞭解一下開發人員須要知道的重要的Git的概念。
GitHub Issues
GitHub Issues是世界上最受歡迎的bug跟蹤器之一。項目的全部者能夠利用它組織，標記和將 issue 與里程碑關聯。
若是你在他人管理的項目上打開某個issue，它將保持打開狀態，直到你將其關閉（若是你找出問題所在）或者項目管理者關閉它。
有時候你會獲得一個明確的答案，而在其餘時候，這個issue將會保持開放並標記一些分類信息。而後開發人員能夠回到這個issue來解決問題或改進你所反饋的代碼庫。
大多數開發人員不能免費管理在 GitHub 上發佈的代碼，一些開放源代碼庫由那些圍繞該代碼提供服務的公司發佈，針對具備更多功能的版本或者利用基於插件的體系結構。因此他們已經爲開源項目付費給開發人員。
社交編碼
幾年前，GitHub標誌包含了「社交編碼」標語。這是什麼意思，是否存在必然聯繫？答案是確定的。
Follow
藉助GitHub，你能夠經過訪問用戶我的資料並點擊「關注」，或點擊repo協議上的「觀看」按鈕來關注開發人員或軟件庫。
在這兩種狀況下，活動都會顯示在你的dashboard中。關注用戶或軟件庫跟Twitter的關注不一樣，你看不到別人說了什麼 ？可是能夠看到別人在作什麼。
Star
GitHub的一大特點就是可以爲軟件庫加Star。用戶能夠經過此操做把某個軟件庫列入「已加星標的軟件庫」列表中，該列表可以幫助跟蹤你感興趣的項目並發現相似的項目。
這也是最重要的評級機制之一，由於得到的星星越多，一般就表明該軟件庫越受歡迎/重要。所以，它在搜索結果中的排名也會更靠前。許多重大項目都有數萬顆恆星。
GitHub也有一個trending頁面，它的特色是在特定的時間段（例現在日/本週、本月）盤點得到最多Star的軟件庫。
進入這些Trending列表可能其餘網絡展現的效果不一樣，例如在其餘網站上會出現，僅僅只是由於你在那個網站常常搜索該軟件庫。
Fork
項目最後一個重要的網絡指標是Fork的數量。
這是GitHub如何工做的關鍵，由於Fork是Pull Request（PR）的基礎，這是一個更改提議。一我的可能會fork你的軟件庫，進行一些更改，而後建立一個PR來要求您合併這些更改。
有時fork軟件庫的人可能永遠不會要求你合併任何東西。他們可能會由於他們喜歡你的代碼而Fork你的倉庫，並在上面添加一些他們不想合併到原始軟件庫的東西。用戶還能夠修復他們遇到的一些bug。
流行=更好
總而言之，這些都是項目受歡迎程度的關鍵指標。除了上述指標以外，最近一次提交的日期和做者參與issue跟蹤系統的信息也是十分有用的，他能夠體現一個軟件庫的可信賴度。
Pull Request（PR）
在前一節中，有介紹了Pull Request（PR）是什麼。重申一下，一我的可能會fork你的存儲庫，作一些改變，而後建立一個PR來要求你合併這些改變。
一個項目可能有數百個PR請求，一般狀況下，項目越受歡迎，它的PR越多，如React項目：
● 一旦一我的提交了PR，須要由項目的核心維護者進行審查。
● 根據你的請求範圍（更改次數，受更改影響的事件數量或涉及代碼的複雜程度），維護人員可能須要不等時間來確保更改與項目兼容。
● 一個項目可能有一個明確的改進時間表，當你在PR請求中引入複雜的體系結構時，維護人員但願你能夠儘量簡單的方式介紹。
也就是說，PR並不老是被立馬處理，而且不能保證PR會被接受。
在我上面發佈的例子中，repo中有一個能夠追溯到一年半之前的PR。這都是十分常見的，緣由就是上面提到的這些。
項目管理
除了issue（開發人員得到用戶反饋的地方）外，GitHub界面還提供了少許項目管理功能。
其中之一是Project。它在生態系統中是比較新的，不多被使用，但它是一個幫助組織完成問題和工做的看板。
該wiki可被用做用戶文檔。Go編程語言的GitHub Wiki是最令我印象深入的。
另外一個受歡迎的項目管理功能是里程碑。它是issue頁面的一部分，你能夠將問題分配給特定的里程碑，其中包括髮布目標。
說到發佈，GitHub 經過引入發佈來加強了Git標籤的功能。
Git標記是特定commit的指針，若是完成時間一致，它能夠幫助你回到以前版本的代碼，而無需引用特定的commit。
GitHub發佈版創建在Git標籤的基礎上，表明代碼的完整版本，也可能表明代碼最終完整工做版本的Zip文件，發行說明和二進制資產。
雖然能夠經過編程建立Git標籤（例如，使用命令行git程序），但GitHub版本是經過GitHub UI手動建立。你能夠利用GitHub建立一個新版本，並選擇你想應用的標籤。
比較commit
GitHub提供了許多處理代碼的工具。
你可能最想要作的事情之一是將一個分支與另外一個分支進行比較。或者你可能但願將最新的commit與您當前使用的版本進行比較，以隨時查看更改。
GitHub容許你使用比較視圖執行此操做：你只要在軟件庫名稱末尾添加/compare 便可。例如：https://github.com/facebook/react/compare
在下圖中，我將最新的React v15.x與最新v16.0.0-rc版本進行比較，以便了解更改內容。
這個視圖給咱們展現了所提交兩個版本（或標籤或commit）已更改，以及之間的實際差別。
Webhooks和服務
GitHub提供了許多有助於開發人員工做流程的功能，例如webhook和服務。
Webhooks
當軟件庫中出現特定問題時，Webhook 能夠觸發外部服務，例如，推送代碼時，建立分支或建立或刪除標記時。
當上述狀況發生時，GitHub會向URL發送POST請求。
此功能的一個常見用法是在咱們從本地計算機上推送更新時，ping遠程服務器能夠從GitHub獲取最新代碼。
GitHub 服務和新的 GitHub 應用程序是第三方集成程序，可改善開發者的體驗或爲用戶提供服務。
例如，您能夠設置一個測試運行器，以便在每次使用TravisCI推送一些新commit時自動運行測試。
你能夠設置 Continuous Integration 來使用 CircleCI。你能夠建立一個Codeclimate集成，分析代碼並提供「Technical Debt」報告和測試覆蓋率。
最後的話
GitHub是一個了不得的工具和服務，是當今開發人員工具種的神器。本教程能夠幫助你入門GitHub，在GitHub開源（或閉源）項目上工做的體驗真的是不容錯過的。