【Github教程】史上最全github使用方法：github入門到精通之三

阿新 • • 發佈：2018-11-28

GitHub已經成為的一切開放原始碼軟體的基石。開發人員喜歡它，基於它進行協作，並不斷通過它開發令人驚歎的專案。除了程式碼託管，GitHub的主要吸引力是使用它作為一個協作開發工具。在本教程中，讓我們來看看一些最有用的GitHub的功能，特別是使團隊工作更有效率，更高生產力，非常重要的，好玩的那些功能！

GitHub和軟體合作

有一件事我覺得非常有用的是，可以將GitHub的維基整合到專案的原始碼主線上。

本教程假定您已經熟悉Git – 開放原始碼的分散式版本控制系統，由Linux的創世人Linus Torvalds在2005年創造的。如果您需要修改或查詢有關Git

，請訪問我們以前的截圖教程，和一些文章。此外，你應該已經有一個Github上的帳戶，並做了一些基本的功能，如建立一個儲存庫，並推送到GitHub上。如果沒有，可以參照更多以前的教程。

在這個世界上的軟體專案，不可避免的是，我們必須和一個團隊一起工作來交付軟體。在本教程中，我們將探索一些軟體開發團隊最常用的工具。這些工具包括：

新增團隊成員 – 組織和合作者
Pull請求 – 傳送程式碼變更和合並
問題跟蹤 – Github上的錯誤記錄
分析 – 圖形與網路
專案管理 – Trello與Pivotal Tracker
持續整合 – Travis CI
程式碼審查 – 程式碼行評論與URL查詢
文件記錄 – Wiki與Hubot

更喜歡截圖操作視訊？

如果你傾向於觀看截圖操作視訊，可以觀看下面的截圖操作視訊，而將本教程作為旁註。

工具一：增加團隊成員

有兩種常用的方法在GitHub上建立團隊合作：

組織 – 組織的所有者可以針對不同的程式碼倉庫建立不同訪問許可權的團隊。
合作者 – 程式碼倉庫的所有者可以為單個倉庫增加具備只讀或者讀寫許可權的協作者。

組織

如果您監管幾個團隊，想為每個團隊設定不同的許可權級別，或者為不同的程式碼倉庫增加不同的成員組織(Organizations)將是最好的選擇。任何GitHub使用者帳戶已經可以建立免費的開原始碼庫的組織。要建立一個組織，只需瀏覽您的

組織設定頁面：

要訪問組織的團隊頁面，你可以簡單地去頁面http://github.com/organizations/[組織名稱]/teams來檢視，或者訪問頁面https://github.com/organizations/[組織名稱]/teams/new來建立新的具備3種不同的許可權級別的團隊成員，如：

Pull Only：提取和合並另一個庫或本地副本。只讀訪問許可權。
Push和Pull：(1)以及更新遠端程式碼倉庫。讀+寫訪問許可權。
Pull, Push和管理：(1), (2)，計費，建立團隊，以及取消組織帳戶。讀+寫+管理員許可權

合作者

合作者主要用於讀寫訪問個人賬號所擁有的程式碼倉庫。你可以通過https://github.com/[使用者名稱]/[程式碼倉庫名稱]/settings/collaboration來增加合作者(其他github個人賬號)。

一旦做到這一點，每個合作者將會看到程式碼庫頁面的訪問狀態的變化。在擁有對程式碼庫的寫訪問許可權後，我們可以做一個git克隆，進行程式碼變更，用git拉取和歸併遠端儲存庫中的任何變化，並最終將本地的變化git推送到遠端程式碼庫：

工具二：Pull請求(Pull request)

Pull請求是一個非常棒的方式，通過fork一個新的程式碼庫用來獨立開發，並將變更貢獻回原始程式碼庫。在一天結束的時候，如果我們願意，我們可以傳送一個pull請求給程式碼庫所有者，來合併我們的程式碼更改。Pull請求本身可以引起合作者之間的評論，包括程式碼質量，功能，甚至總體戰略等。

現在讓我們瀏覽一個pull請求的基本步驟。

發起一個Pull請求

GitHub有兩種Pull請求方式：

Fork & Pull 方式 – 用於在公共庫中，我們沒有推送(push)許可權。
共享庫方式 – 用於私有程式碼倉庫，我們有推送(push)許可權。這種情況下沒有必要進行fork。

下面的工作流程是在兩個使用者(原始程式碼庫擁有者，和fork程式碼庫擁有者)之間的fork-pull方式：

進入你想貢獻修改的GitHub程式碼庫，單擊“Fork”按鈕來建立自己的Github帳戶上的程式碼庫克隆：
這將在自己的帳戶上建立一個該程式碼庫的複製：
選擇 SSH URL,那樣它會自動使用你自己的SSH金鑰，而不用每次在git pull或者push時詢問你的使用者名稱和密碼。下一步，我們將克隆一份程式碼庫到本地計算機：
```
$ git clone [ssh-url] [folder-name]
$ cd [folder-name]
```
一般情況下，每一個新的功能，我們將建立一個新的Git分支。這是一個很好的做法，因為在未來，如果經過一番討論後我們需要進一步更新分支，Pull請求將被自動更新。讓我們建立一個新的分支做一個非常簡單的變化修改的readme.md檔案：
```
$ git checkout -b [new-feature]
```
在為這個新功能增加檔案後，我們只需要將修改提交到這個新分支上，然後切換回master分支:
```
$ git add .
$ git commit -m "information added in readme"
$ git checkout master
```
在這裡，我們需要將新分支推送到遠端程式碼倉庫裡。首先，我們需要檢查這個新功能的分支名稱以及其在遠端倉庫的別名，然後我們用git push [git-remote-alias] [branch-name]推送這個變更。
```
$ git branch
* master
readme
$ git remote -v
origin  [email protected]:[forked-repo-owner-username]/[repo-name].git (fetch)
origin  [email protected]:[forked-repo-owner-username]/[repo-name].git (push)
$ git push origin readme
```
進入我們fork的程式碼庫的GitHub頁面，選擇為這個新功能建立的分支，然後點選Pull Request按鈕：
提交Pull請求後，頁面將直接跳轉到原始庫的Pull請求頁面，我們將看到我們提交的Pull請求，作為一個新的問題，以及作為一個新的pull請求。
在經過討論後，fork的程式碼庫的作者可能想為這個新功能增加一些新的改動。在這種場景下，我們需要在本地計算機上checkout這個同樣的分支，修改，提交，並推送回GitHub。當我們再次訪問原始碼庫的pull請求頁面的時候，會發現上次提交的Pull請求已經自動更新了。

合併一個Pull請求

如果你是原始程式碼庫的所有者，你將有兩種方式來合併收到的Pull請求。

直接在GitHub上合併：如果我們想直接在GitHub上進行合併，必須確保沒有衝突。原始庫的所有者可以通過簡單地點選Merge Pull Request按鈕來進行合併：
在本地計算機上進行合併：另外一種情況，合併的時候可能會遇到衝突，點選上部的Info圖示，GitHub有非常清晰的指導，怎麼從貢獻者的分支上下拉程式碼變更到本地，合併並解決衝突。

在軟體開發團隊中有很多不同的程式碼分支模型。這裡有兩種非常常用的工作流程模型：

簡單分支模型以及Pull請求;
更加廣泛的分支模型.

至於採用何種分支模型，取決於團隊，專案，以及當時的狀態。

工具三：錯誤跟蹤

在GitHub中，缺陷跟蹤的中心是問題列表(Issues)。雖然問題列表主要是為了跟蹤缺陷，但我們經常會用以下面的方式：

缺陷：軟體中顯然壞了的行為，需要進行修正的地方。
功能：需要實現的很酷很棒的新點子。
待完成清單：待完成的檢查清單。

讓我們來探討問題列表的一下特點：

標籤：具有不同顏色的類別，用來幫助過濾問題。
里程碑：附加在每一個問題上的日期分類，可用於確定哪些問題需要在下一個版本解決。此外，由於每個問題都定有里程碑，每當一個問題解決，它會自動更新進度條。
搜尋：搜尋時能自動列出匹配的問題列表和里程碑。
分配：每個問題都能分配一個人負責進行解決，同時這也能讓我們知道目前我們需要工作在什麼上面。
自動關閉：包含Fixes/Fixed/Close/Closes/Closed #問題編號的提交記錄，將自動關閉該問題。
```
$ git add .
$ git commit -m "corrected url. fixes #2"
$ git push origin master
```
很顯然，我們能將任務清單與程式碼提交緊密地耦合在一起。
提及或者引用：任何人在評論的時候在訊息文字中包含#[問題編號]，將自動生成該問題的連結，使得在討論的過程中能非常容易地提及相關的問題。

工具四：分析

有兩個工具-圖形和網路，讓我們能洞察儲存庫的變化。Github圖提供了程式碼庫的合作者，以及程式碼提交的直觀展現，而Github網路視覺化直觀地展現了每一個貢獻者和他們在所有分支上的程式碼提交。這些分析和圖形非常強大，尤其是當在團隊中工作。

圖(Graphs)

圖提供了詳細的分析，包括：

貢獻者：有哪些程式碼提交者？他們增加或者刪除了多少程式碼行？
程式碼提交活動：在過去的一年中，這些程式碼提交主要發生在哪些周？
程式碼頻率：在整個專案的生命週期的不同階段，提交了多少程式碼行？
記錄卡：程式碼提交通常發生在每一天的什麼時候？

網路(Network)

GitHub網路(Network)是一個非常強大的工具，讓我們能看到每一個貢獻者的程式碼提交，以及這些提交與其他的提交有什麼關聯。當我們作為一個整體觀看這個網路的視覺化展現時，我們能看到每一個庫，每一個分支，和每一個提交，

工具五：專案管理

GitHub上的問題列表可以定義問題和里程碑，具有一定的專案管理能力。因為其他的某些功能或現有的工作流程，有些團隊可能會更傾向於另外的工具。在本節中，我們將看到我們如何連線Github與其他流行的專案管理工具 – Trello和Pivotal Tracker。使用GitHub的服務鉤子(hooks，我們可以將程式碼提交，問題和許多其他活動自動更新到任務中。對於任何軟體開發團隊，這種自動化的幫助，不僅節省了時間，而且還可以提高更新的。

GitHub和Trello

Trello提供了一直簡單而直觀的方式管理任務。使用敏捷開發的方式， Trello任務卡能模擬簡單，視覺化的虛擬任務看版。作為例項，當GitHub程式碼庫收到一個Pull請求的時候，我們將利用GitHub的鉤子(Hooks)服務，自動在Trello裡生成一個任務卡。讓我們來看看實現這個功能的具體步驟：

首先註冊一個Trello帳號，並建立一個新的Trello看版(Board)。
訪問GitHub repository > Settings > Service Hooks > Trello。
通過Install Note #1描述的方法獲得認證用的令牌(Token)。
通過Install Note #2給的連結獲得json格式的任務列表(list) id。BOARDID是我們訪問網站看版的URL中的一部分https://trello.com/board/[BOARD-NAME]/[BOARDID]。
回到GitHub的鉤子服務，輸入我們得到的list id和token，啟用這個hook，可以通過Test Hook按鈕來測試每次收到新的Pull請求時，是否自動更新看版內容。
當下次收到新的Pull請求時，Trello看版就會自動生成一個Pull請求任務卡。

GitHub和Pivotal Tracker

Pivotal Tracker是另外一個輕量級的專案管理工具，通過基於故事(story)的計劃，讓組員能對任何變化和進度進行迴應，非常容易進行協作開發。基於專案當前的進度，能生成視覺化的圖表來分析團隊的開發速度，迭代burn-up圖，以及當前釋出的burn-down圖。在下面的例子中，我們通過關聯一個GitHub程式碼提交(commit)到故事(story)，自動地交付一個故事。

在Pivotal Tracker上新建一個專案，並生成一個需要交付的故事(story)。
訪問Profile > API Token，複製給定的API令牌(token)。
返回到GitHub頁面訪問repository > Settings > Service Hooks > Pivotal Tracker，貼上剛才複製的token，啟用，並儲存設定。這樣我們就能夠在提交程式碼的時候自動交付對應的故事(story)。
當我們最終提交程式碼修訂的時候，按照格式git commit -m "message [delivers #tracker_id]" 將故事的id新增到提交記錄裡。
```
$ git add .
$ git commit -m "Github and Pivotal Tracker hooks implemented [delivers #43903595]"
$ git push
```
現在，返回到Pivotal Tracker頁面，我們將發現這個指定的故事被自動的釋出出去了，附著對應的GitHub上程式碼提交的連結。

通過Trello和Pivotal Tracker例項，非常清楚的一點是我們能緊密地將我們的任務和程式碼提交繫結在一起。當作為一個團隊進行工作的時候，這將節省大量的時間，並且提高工作記錄的精確度。非常好的訊息是，如果你已經使用了其他專案管理工具，例如Asana，Basecamp，或者其他的，你能夠用類似的方式新增hook。如果沒有你目前正在使用的專案管理工具的hook，自力更生自己做一個！

工具六：持續整合

對於團隊軟體開發來說，持續整合(CI)是一個非常重要的部分。CI確保當開發人員提交程式碼改動的時候，將觸發自動的構建(build)，包括測試，用來快速地檢測軟體整合的錯誤。這將毫無疑問地減少整合過程中的錯誤，提高快速開發迭代的效率。在下面的例子裡，我們將看到如何與GitHub一起使用Travis CI，自動檢測錯誤，並且在所有測試通過後進行程式碼合併。

設定 Travis CI

這裡我們使用基於node.js伺服器，基於[grunt.js][http://gruntjs.com/]作為構建工具的”Hello-World”應用，來設定Travis CI專案。下面是專案中的檔案：

hello.js檔案是nodejs專案。我們有目的地漏寫了一個分號，為了讓這個檔案不能通過grunt構建工具的lint(靜態程式碼檢測工具)：

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World in Node!\n') // 這裡沒有分號，將不會通過linting
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

package.json定義依賴的包：

{
  "name": "hello-team",
  "description": "A demo for github and travis ci for team collaboration",
  "author": "name <[email protected]>",
  "version": "0.0.1",
  "devDependencies": {
    "grunt": "~0.3.17"
  },
  "scripts": {
    "test": "grunt travis --verbose"
  }
}

為了簡化起見，gruntjs構建工具的配置檔案僅僅包含一個任務(linting)：

module.exports = function(grunt) {
  grunt.initConfig({
    lint: {
      files: ['hello.js']
    }
  });
  grunt.registerTask('default', 'lint');
  grunt.registerTask('travis', 'lint');
};

.travis.yml是Travis的配置檔案，確保Travis執行我們的測試：
```
language: node_js
node_js:
  - 0.8
```
接著，用GitHub帳號登入到Travis，在repository選項卡開啟repository hook:
如果上述步驟還不能觸發構建，我們將不得不手工配置hook，在Travis的profile欄複製token。
返回到GitHub程式碼庫，使用複製的token設定Travis Hook：
第一次，我們必須手工做一次git push來觸發Travis構建，如果一切ok，我們可以訪問http://travis-ci.org/[使用者名稱]/[repo名]檢視構建的結果。

Travis CI 和 Pull 請求(Pull request)

以前沒有持續整合的Pull請求流程，步驟大概是(1)提交pull請求(2)合併(3)測試來看是否通過或者失敗。帶有持續整合hook的Pull請求流程將反轉(2)和(3)步驟，Travis CI將向我們彙報每一個Pull請求的持續整合結果，讓我們能夠知道這個Pull請求是否足夠好，並快速作出判斷是否合併進主線。下面我們來看這是怎樣做到的：

提交一個附帶通過構建結果的Pull請求。Travis將做所有的一切，讓我們在合併前就能知道這個合併是否足夠好。
如果這個Pull請求使得構建失敗，Travis同樣會警告你：
如果我們點選紅色的警告連結，瀏覽器將跳轉到Travis頁面，顯示這次構建的詳細資訊。

因為自動的構建和及時地通知，Travis CI對團隊來說非常有幫助，它能極大地縮短我們更正錯誤的週期。如果你使用另外一個非常有名的持續整合工具Jenkins，你能用相似的步驟設定hook服務。

工具七：程式碼評審

對於每個提交(commit)，GitHub有個乾淨的介面用來進行評論，甚至是對某行程式碼進行評論。在進行逐行程式碼評審的時候，針對單行程式碼提出評論和問題的功能就顯得非常重要了。開啟提交(commit)介面的頂部的檢查框，就能顯示行內評論。

下面探討一些幫助我們進行程式碼評審，能快速顯示不同提交之間差異的URL模式：

對比branch/tags/SHA1：使用URL模式https://github.com/[username]/[repo-name]/compare/[starting-SHA1]...[ending-SHA1]。可以用分支或者標籤名代替SHA1。
去除空格進行對比：增加?w=1到對比的URL尾部。
Diff：增加.diff到URL的後面能得到git diff輸出的純文字資訊。在寫指令碼的時候，這個功能非常有用。
Patch：增加.patch到URL的後面能得到電子郵件補丁提交格式的git diff輸出的資訊。
行連結：在檢視檔案時，點選任何行號，GitHub將會在URL後面增加一個#行號，並且將該行的背景顏色置成黃色。這能幹淨利落地標識程式碼檔案的某一行。我們同樣能通過增加#開始行號-結束行號來指定一個範圍。這裡是行連結和行範圍連結的例子。

工具八：文件

在這段，我們將探討兩種文件方法：

正式文件：使用GitHub Wiki生成正式的專案文件。
非正式文件：使用GitHub Hubot來歸檔團隊內部的討論，以及與Hubot互動而自動獲得的非常有趣的資訊。
提及，快捷鍵和表情符號

GitHub維基(Wiki)

每個GitHub程式碼庫都可以生成一個維基，這樣非常方便地將程式碼和文件存放在同一個儲存庫中。要建立維基，訪問主標題的維基選項卡，並設定建立頁面的資訊。其實維基也有自己的版本，並可以將資料複製到本地機器進行更新，甚至是離線訪問。

有一件事我覺得非常有用的是可以將GitHub的維基整合到原始碼中，這樣我就不必維護兩個獨立的Git專案了。要做到這一點，我將Wiki作為git子模組增加到主分支上。如果您使用的是Travis CI或任何其他CI，必須確保構建工具會忽略wiki的子模組。在Travis的CI檔案.travis.yml中，新增以下內容：

git:
  submodules: false

接著增加一個git子模組wiki到主程式碼庫中：

$ git submodule add [email protected]:[username]/[repo-name].wiki.git
Cloning into 'hello-team.wiki'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
$ git add .
$ git commit -m "added wiki as submodule"
$ git push origin master

現在，維基就作為一個子模組顯示在程式碼庫專案中。

GitHub Hubot

Hubot，總之，可以極大地增添了不少的樂趣記錄，並通知小組討論重要的提交。

Hubot是一個簡單的聊天機器人，可以檢索資訊，或提供通知，每當GitHub有程式碼提交，問題，或活動時。在一個旨在減少，甚至完全消除會議的一個團隊中，Hubot擁有所有團隊成員的聊天介面，幫助您記錄著每一個討論。這當然促進靈活的工作時序，因為團隊沒有必要同時出席討論。警告：Hubot是非常上癮的！

有了這個，讓我們開始在Heroku上設定Hubot，擁有Campfire聊天介面的聊天機器人！[Heroku][]和Campfire，都有免費的版本供大家開始嘗試。

我們將使用GitHub出品的支援Campfire的Hubot。如果你願意，也可以使用其他如Skype，IRC，GTalk等聊天介面卡。
建立一個僅為Hubot的Campfire賬號，這個賬號將新建一個房間，並邀請其他人加入。
根據Hubot維基上給的指示，部署Hubot到Heroku上。如果Heroku的應用程式的URL返回了一個Cannot GET /，別驚慌，因為預設情況下不會得到任何返回。
從Hubot Campfire賬號上，邀請你自己的賬號，現在，登入你自己的Campfire賬號，然後執行Hubot help，你將得到所有Hubot支援的命令。
嘗試幾次，例如Hubot ship it或者Hubot map me CERN。
下一步，我們將增加一個Hubot指令碼，這裡已經有大量的指令碼，附帶命令說明。
作為例項，我們將增加一個github提交指令碼，以至於每次有一個新的提交，Hubot將在聊天室通知大家。將檔案github-commits.coffee放置到scripts目錄。
更新package.json檔案，根據每個指令碼檔案頭的指示，加入新的依賴包。
使用下面命令再一次釋出程式碼到Heroku：git push heroku master
瀏覽GitHub程式碼庫，我們希望程式碼提交通知能顯示在聊天室，在程式碼庫設定下增加一個web hook，對github-commits指令碼，webhook將是[HUBOT_URL]:[PORT]/hubot/gh-commits?room=[ROOM_ID]
下一次當代碼庫有新的程式碼提交，Hubot將在聊天室如此說：

檢查其他Github相關的Hubot的指令碼，或者如果您想自己寫一個指令碼，這裡有一個很酷的教程！總之，Hubot可以極大地增添很多樂趣在文件記錄、通知小組討論程式碼庫發生的重要提交，問題和活動。試試看吧！

關於和團隊一起使用GitHub，最後要說明的是，這裡有一些提高生產力的技巧：

提及(Mentions) – 在任何文字區域中，我們可以通過@使用者名稱提到另外一個GitHub使用者，並且該使用者將得到通知。
快捷鍵 – 按SHIFT + ?可以檢視Github上任何頁面上的快捷鍵。
表情符號 – 通過使用表情符號，Github上的文字區域還支援插入的圖示。來吧，與隊友一起工作時有點情趣！

GitHub上非軟體專案的合作

我們大多數人會認為使用Github只能為軟體專案。畢竟，Github產生就是為了社交程式設計。但是，也有一些很酷的使用Github的庫被用於非編碼專案，和他們的合作和討論同樣非常棒。因為這些專案是開源的，任何人都可以作出貢獻，這是快速修復錯誤，容易報告錯誤，與志同道合的人有效的合作。只是為了好玩，這裡是其中的一些：

房屋修復: 房屋的問題跟蹤
書籍: Little MongoDB Book, Backbone Fundamentals
歌詞: JSConfEU Lyrics
找男朋友: boyfriend_require
教導: Wiki
基因組資料: Ash Dieback epidemic
部落格: CSS Wizardry

你能想象GitHub開發團隊怎麼認為這些專案？

“我們挖掘像這樣一樣使用GitHub的樂趣！”