開發人員每天都要在工作中使用 GitHub 或其他基于 Git 的工具。 GitHub 是面向開源及私有軟件項目的托管平臺。 那么什么是 GitHub？其中都有哪些關鍵的概念？如何使用 GitHub 才能提高工作效率？

　　本文編譯自 medium 上原標題為 A developer’s introduction to GitHub 的文章。

　　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 將會被打開并標記出一些分類信息。 然后開發人員可以回到這個 issue 來解決問題或根據反饋改進代碼庫。

　　大多數開發人員不會免費管理在 GitHub 上發布的代碼，因此您不能期望即時回復。 但是一些開放源代碼庫由那些圍繞該代碼提供服務的公司發布，它們會提供具有更多功能的版本或者使用基于插件的系統。 這些公司已經為開源項目付給開發人員工資。

　　社會編碼

[[221772]]

　　幾年前，GitHub 標志出現了“社交編碼”。

　　這是什么意思，和 GitHub 有什么關系呢？

　　Follow

　　使用 GitHub，您可以通過訪問用戶的個人資料并單擊“關注”，或者通過單擊軟件庫上的“觀看”按鈕來關注開發人員或軟件庫。

　　在這兩種情況下，活動都會顯示在您的 dashboard 中。關注用戶或軟件庫跟 Twitter 上的關注不一樣，你看不見人們說什么，而可以看到人們在做什么。

　　Star

　　GitHub 的一大特色就是能夠為軟件庫加星標。用戶可以通過這個操作將其他軟件庫加入到“已加星標的軟件庫”列表中，這樣用戶可以關注自己感興趣的項目并發現類似的項目。

　　這也是最重要的評級機制之一，因為軟件庫的星星越多，它通常就越受歡迎和重要。它在搜索結果中也會位于更突出的位置。

　　重大項目可能有數萬顆星。

　　GitHub 也有一個 trending 頁面，它會推薦在特定時間段內（例如今天或本周或本月）獲得最多星星的軟件庫。

　　Fork

　　項目最后一個重要的網絡指標是 fork 的數量。

　　這是 GitHub 如何工作的關鍵，因為 fork 是 Pull Request（PR）的基礎，這是一個更改提議。一個人可能會 fork 您的軟件庫，進行一些更改，然后創建一個 PR 來要求您合并這些更改。

　　有時 fork 軟件庫的人可能永遠不會要求你合并任何東西。他們可能會因為喜歡你的代碼而 fork 你的軟件庫，并在上面添加一些他們不想合并到原始軟件庫的東西。用戶還可以修復他們遇到的 bug。

　　受歡迎=更好

　　總而言之，這些都是項目受歡迎程度的關鍵指標。 除了上述指標之外，最近一次提交的日期和作者參與 issue 跟蹤系統的信息也是衡量軟件庫或軟件可信度的標準之一。

　　PR（Pull Request）

　　在前一節中，我介紹了 Pull Request（PR）是什么。 重申一下，一個人可能會 fork 你的軟件庫，做一些改變，然后創建一個 PR 來要求你合并這些改變。

　　一個項目可能有數百個 PR，通常情況下，項目越受歡迎，它的 PR 越多，如 React 項目：

　　一旦一個人提交了 PR 請求，項目的核心維護者就會對其進行審查。

　　根據請求范圍（更改次數，受更改影響的事件數量或涉及到的代碼的復雜程度），維護人員可能需要不等的時間來確保更改與項目兼容。

　　一個項目可能有有關改進的明確時間表。維護人員希望用戶用盡可能簡單的方式介紹 PR 中的體系結構。

　　這就是說，PR 并不總是被立馬接受，并且可能不會被接受。

　　在我上面的例子中，軟件庫中有一個一年半前的 PR。這在所有項目中都會發，很正常，可能是由于我上面提到的原因。

　　項目管理

　　除了 issues（開發人員獲得用戶反饋的地方）外，GitHub 界面還提供了少量項目管理功能。

　　其中之一是 Projects。它在生態系統中是非常新的，也很少被使用，但它是幫助用戶組織需要完成的問題和工作的看板。

　　Wiki 可以被用作文檔。另一個受歡迎的項目管理功能是里程碑。它是 issue 頁面的一部分，您可以將問題分配給特定的里程碑，可能是發布目標。

　　說到發布，GitHub 通過引入發布增強了 Git 的標簽功能。

　　Git 標簽是特定 commit 的指針，如果完成時間一致，它可以幫助您回到之前版本的代碼，并且無需引用特定的 commit。

　　GitHub 發布版建立在 Git 標簽的基礎上，代表代碼的完整版本，也可能代表代碼最終產品完整工作版本的 Zip 文件，發行說明和二進制資產。

　　盡管可以通過編程創建 Git 標簽（例如，使用命令行 git 程序），但創建 GitHub 版本是手動過程，在 GitHub UI 上進行。用戶可以利用 GitHub 創建一個新版本，并選擇你想應用的標簽。

　　比較 commits

　　GitHub 提供了很多處理代碼的工具。

　　您可能最希望做的事情之一是將一個分支與另一個分支進行比較。 或者您可能希望將最新的 commit 與您當前使用的版本進行比較，以便隨時查看更改。

　　用戶可以利用 GitHub 比較視圖執行此操作：只需在軟件庫名稱末尾添加/compare 即可。

　　例如，https://github.com/facebook/react/compare

　　在下圖中，我將最新的 React v15.x 與最新 v16.0.0-rc 版本進行了比較，方便大家了解更改的內容。

　　該視圖向您展示了兩個版本（或標簽或 commits）之間的不同以及實際差異。

　　Webhooks 和服務

　　GitHub 提供了許多有助于開發人員工作流程的功能，例如 webhook 和服務。

　　Webhooks

　　當軟件庫中出現特定問題時，Webhook 可以觸發外部服務，例如，推送代碼時，創建分支或刪除標簽。

　　當問題發生時，GitHub 會給 URL 發送 POST 請求。

　　當我們從本地計算機推送更新時，此功能能 ping 遠程服務器以從 GitHub 獲取最新代碼。

　　服務

　　GitHub 服務和新的 GitHub 應用程序是第三方集成程序，可改善開發者的體驗或為用戶提供服務。

　　例如，您可以設置一個測試運行器，這樣每次 TravisCI 推送新 commits 時，它可以自動運行測試。

　　您可以設置 Continuous Integration 來使用 CircleCI。您也可以創建一個 Codeclimate 集成程序來分析代碼并創建“Technical Debt”報告和測試覆蓋率。

　　小結

　　GitHub 是一個了不起的工具和服務平臺，是當今開發人員可以利用的真正神器。本教程只是入門級，但在 GitHub 上工作是不容錯過的。

　　原文作者：Flavio Copes