【讀書筆記】GitHub入門

代碼管理方式——集中與分散

集中型

以 Subversion 爲表明的集中型，所示將倉庫集中存放在服務器之中，因此只存在一個倉庫。這就是爲何這種版本管理系統會被稱做集中型。

集中型將全部數據集中存放在服務器當中，有便於管理的優勢。可是一旦開發者所處的環境不能鏈接服務器，就沒法獲取最新的源代碼，開發也就幾乎沒法進行。服務器宕機時也是一樣的道理，並且萬一服務器故障致使數據消失，恐怕開發者就再也見不到最新的源代碼了。

分散型

GitHub 將倉庫 Fork 給了每個用戶。Fork 就是將 GitHub 的某個特定倉庫複製到本身的帳戶下。Fork 出的倉庫與原倉庫是兩個不一樣的倉庫，開發者能夠隨意編輯。

分散型擁有多個倉庫，相對而言稍顯複雜。不過，因爲本地的開發環境中就有倉庫，因此開發者沒必要鏈接遠程倉庫就能夠進行開發。

GitHub相關

快捷鍵

在 GitHub 中，不少頁面均可以使用鍵盤快捷鍵。在各個頁面按下 shift ＋ / 均可以打開鍵盤快捷鍵一覽表，查看當前頁面的快捷鍵。

Explore

從各個角度介紹 GitHub 上的熱門軟件。

• GitHub 公司特別介紹的軟件（附開發者製做的視頻）
• 按語言篩選本日 / 周 / 月的熱門倉庫 / 開發者

Gist

Gist 功能主要用於管理及發佈一些不必保存在倉庫中的代碼，好比小的代碼片斷等。系統會自動管理更新歷史，而且提供了 Fork 功能。在 Gist 上添加的代碼示例能夠嵌入博客中。固然，若是選擇了語言，還會自動添加語法高亮。

Blog

這是到 GitHub 公司官方博客的超連接，GitHub 公司會在上面發佈通知。新功能的通知、新入職員工的介紹、drinkup 聚會的信息等都會在上面按期發佈。

github上的交流：

GitHub 中可以使用的描述方法並不止「@ 用戶名」一種。

輸入「@ 組織名」可讓屬於該 Organization（組織）的全部成員收到通知 7。輸入「@ 團隊名」可讓該團隊的全部成員收到通知。這就是同時向多人發送通知的方法。

輸入「# 編號」，會鏈接到該倉庫所對應的 Issue 編號。輸入「用戶名 / 倉庫名 # 編號」則能夠鏈接到指定倉庫所對應的 Issue 編號。只要按照這類特定格式書寫便會自動建立連接。

只要將感興趣的倉庫添加至 Watch 中，就能夠在 News Feed 查 看該倉庫的相關信息。

News Feed

顯示當前已 Follow 的用戶和已 Watch 的項目的活動信息，用戶能夠在這裏查看最新動向。將右上角 RSS 標誌的 URL 添加到 RSS 閱讀器中，還能夠經過 RSS 查看。

Issues

在這裏能夠查看用戶擁有權限的倉庫或分配給本身的 Issue。當用戶同時進行多個項目時，能夠在這裏一併查看 Issue。

Broadcast

主要用於接收 GitHub 公司發來的通知或使用技巧的小貼士。

Your Repositories

按更新時間順序顯示用戶的倉庫。標有鑰匙圖案的是非公開倉庫，標有相似字母 Y 圖案的是用戶 Fork 過的倉庫。

Public contributions

一格表示一天，記錄當日用戶對擁有讀取權限的倉庫的大體貢獻度。貢獻度的衡量標準包括髮送 Pull Request 的次數、寫 Issue 的次數、進行提交的次數等。顏色越深表明貢獻度越高。

Public Activity

從這裏能夠了解到該用戶日常都在 GitHub 上作些什麼。好比查看一下崇拜已久的程序員的公開活動，就能夠知道他如今關注些什麼，或者正在熱心於開發些什麼。

Pull Requests

在 Pull Requests 中能夠列表查看並管理 Pull Request。代碼的更改和討論均可以在這裏進行。旁邊顯示的數字表示還沒有 Close 的 Pull Request的數量。

Pulse

顯示該倉庫最近的活動信息。該倉庫中的軟件是無人問津，仍是在火熱地開發之中，從這裏能夠一目瞭然。

Graphs

以圖表形式顯示該倉庫的各項指標。讓用戶輕鬆瞭解該倉庫的活動傾向。

Clone in Desktop

啓動 GitHub 專用的客戶端應用程序並進行 clone。

releases

顯示倉庫的標籤（Tag）列表。同時能夠將標籤加入時的文件以歸檔形式（ZIP、tar.gz）下載到本地。軟件在版本升級時通常都會打標籤，若是須要特定版本的文件，能夠從這裏尋找。

Compare & review

能夠查看當前顯示的分支與其餘分支的差異，以便進行審查。點擊這個按鈕，會出現一個頁面讓用戶選擇比較對象。

行連接

文件內容的左側會顯示該文件的行號。假如咱們點擊第 10 行的行號，這一行就會被高亮標記爲黃色，同時 URL 末尾會自動添加「#L10」。使用這個 URL，程序員們在交流時，就能夠將討論明確指向某一行。另外，若是將「#L10」改爲「#L10-15」，則會標記該文件的第10～15 行。

在倉庫頁面試着按下鍵盤的 t 鍵，而後輸入要找的目錄或文件的部分名稱。篩選器會在倉庫的目錄和文件中進行篩選，搜索出您要找的文件。

URL使用技巧

• https://github.com/rails/rails/compare/4-0-stable...3-2-stable

這樣，就能夠查看兩個分支間的差異。

• https://github.com/rails/rails/compare/master@{7.day.ago}...master

查看 master 分支在最近 7 天內的差異，支持day，week，month，year。若是差異過大則不會列出全部提交，只顯示最近的一部分。

• https://github.com/rails/rails/compare/master@{2013-01-01}...master

查看 master 分支 2013 年 1 月 1 日與如今的區別。可是若是指定日期與如今的差異過大，或者指定日期過於久遠，則沒法顯示。

Issue

用於 BUG 報告、功能添加、方向性討論等，將這些以 Issue 形式進行管理。Pull Request 時也會建立 Issue。旁邊顯示的數字是當前處於Open 狀態的 Issue 數。

在軟件開發過程當中，開發者們爲了跟蹤 BUG 及進行軟件相關討論，進而方便管理，建立了 Issue。管理 Issue 的系統稱爲 BTS（Bug Tracking System，BUG 跟蹤系統）。當今具備表明性的 BTS 有 Redmine，Trac，Bugzilla等。GitHub 也爲自身加入了 BTS 的功能。

• 支持markdown語法
• 支持指定語法時代碼高亮
• 支持拖拽添加圖片
• 支持添加標籤整理 Issue
• 支持添加里程碑來管理 Issue（相似於進度條的一個東西）

CONTRIBUTING.md

在描述 Issue 時，經常會看到貢獻規範的連接。

在該倉庫的根目錄下添加 CONTRIBUTING.md 文件後該連接就
會顯示出來。規範的內容通常包括報告時Issue的描述方法、Pull Request 時的規則或要求、許可證的相關信息等。爲了在開源項目開發中能與其餘人和諧相處，請務必在貢獻以前仔細閱讀這些規範。

Tasklist語法

使用 GFM 的一項獨有功能，那就是 Tasklist 語法。

# 本月要作的任務
- [ ] 完成圖片
- [x] 完成部署工具的設置
- [ ] 實現抽籤功能

提交與Issue的交互

在 Issue 一覽表中咱們能夠看到，每個 Issue 標題的下面都分配了諸如「#24」的編號。只要在提交信息的描述中加入「#24」，就能在 Issue 中顯示該提交的相關信息，使關聯的提交一目瞭然。這裏只需輕輕點擊一下即可以顯示相應提交的具體內容，在代碼審查時省去了從大量提交日誌中搜索相應提交的麻煩，很是方便。

若是一個處於 Open 狀態的 Issue 已經處理完畢，只要在該提交中如下列任意一種格式描述提交信息，對應的 Issue 就會被 Close。

• fix #24
• fixes #24
• fixed #24
• close #24
• closes #24
• closed #24
• resolve #24
• resolves #24
• resolved #24

Issue與Pull Request

在 GitHub 上，若是給 Issue 添加源代碼，它就會變成咱們立刻要講到的 Pull Request。Issue 與 Pull Request 的編號相互通用，經過 GitHub的 API 能夠將特定的 Issue 轉換爲 Pull Request，可以完成這一操做的是 hub 命令。

Pull Requests

顯示用戶已進行過的 Pull Request。經過這裏，開發者能夠很方便地追蹤 Pull Request 的後續狀況。

Pull Request 是用戶修改代碼後向對方倉庫發送採納請求的功能。在列表中點擊特定的 Pull Request 就會進入詳細頁面。頁面上方顯示着此次是從誰的哪一個分支向誰的哪一個分支發送了 Pull Request。

連接妙用

假設 Pull…Request 的 URL 以下所示。

https://github.com/用戶名/倉庫名/pull/28

若是想獲取 diff 格式的文件，只要像下面這樣在 URL 末尾
添加 .diff 便可。

https://github.com/用戶名/倉庫名/pull/28.diff

同 理， 想 要 patch 格 式 的 文 件， 只 需 要 在 URL 末 尾 添加 .patch 便可。
　　　
https://github.com/用戶名/倉庫名/pull/28.patch

Conversation

能夠查看與當前 Pull Request 相關的全部評論以及提交的歷史記錄。提交日誌的右側有該提交的哈希值，點擊連接便可確認相應提交的詳細信息。

可使用R鍵快速引用選中的評論。

Commits

在 Commits 標籤頁中，按時間順序列表顯示了與當前 Pull Request相關的提交。標籤上的數字爲提交的次數。每一個提交右側的哈希值能夠鏈接到該提交的代碼。

在評論中輸入「:」（冒號）便會啓動表情自動補全功能。只要輸入幾個與該表情相關的字母，系統就會爲您篩選自動補全的對象。選擇想要的表情，其相應代碼（先後都有冒號的字符串）便會插入到文本框中。

（請登陸 http://www.emoji - cheat - sheet.com/ 查找可以使用的表情）

Files Changed

Files Changed 標籤頁中能夠查看當前 Pull Request 更改的文件內容以及先後差異。標籤上的數字表示新建及被更改的文件數。默認狀況下系統會將空格的不一樣也高亮顯示，因此在空格有改動的狀況下會難以閱讀。這時只要在 URL 的末尾添加「?w=1」就能夠不顯示空格的差異。將鼠標指針放到被更改行行號的左側，咱們會看到一個加號。點擊這個加號能夠在代碼中插入評論。這樣，評論是針對哪行代碼的就一目瞭然了。

Wiki

Wiki 是一種比 HTML 語法更簡單的頁面描述功能。經常使用於記錄開發者之間應該共享的信息或軟件文檔。數字表示當前 Wiki 的頁面數量。全部
有權限的人均可以對文章進行修改，因此比較適合多人共同編寫文章的狀況。建立、編輯文檔時沒必要另外啓動軟件，用起來十分方便，很是適合用來針對更新頻率較高的軟件進行文檔等信息方面的彙總。通常狀況下，Wiki 中記載着軟件相關的 FAQ、文檔、代碼示例及解說等信息。

• 支持GFM。
• Wiki 功能自己的數據也在 Git 中進行管理。
  • 用戶可以經過 clone操做獲取 Wiki 倉庫，而後在本地建立、編輯頁面，進行提交再 push，即可以完成對 Wiki 的建立及編輯工做。
• 在 Pages 標籤頁中能夠列表查看 Wiki 頁面。
• 在 History 標籤頁中能夠查看 Wiki 的修改歷史記錄。
• 全部 Wiki 頁面均可以顯示側邊欄。
  • 作法很簡單，只要建立名爲「_sidebar」的頁面便可。_sidebar 頁不會顯示在 Pages 的頁面一覽中。在編輯各頁面時頁面下部會附加 Sidebar 段，用戶能夠在這裏編輯側邊欄的內容。

Graphs

在 Graphs 頁中，能夠經過 4 種圖表查看該倉庫的相關統計信息。

Code Frequency

Code Frequency 中顯示了該倉庫中代碼行數的增長量和刪除量。一款優秀的軟件並不會一味地增長代碼，在通過重構以後，代碼量每每會下降。

Punchcard

從 Punchcard 的圖中咱們能夠直觀地掌握一週內天天什麼時候收到的提交最多。黑色圓越大，表示提交越頻繁。倉庫的關鍵人物每每會出如今提交頻率高的時間段，所以用戶發送的 Pull Request 最有可能在這段時間內被處理。大體瞭解時間規律，將有助於各位把握好發送 Pull Request 以及等待回覆的時間點。另外，該軟件的開發是集中在早上仍是晚上，從這張圖中也可一目瞭然。

Network

以圖表形式顯示包括克隆倉庫在內的全部分支的提交。從圖上能夠直觀地看出每一個人作了多少工做。將鼠標指針停留在表中提交或合併的點上，能夠查看相應的參考內容。

Settings

關於倉庫的設置。

GitHub Pages

GitHub 有一個名爲 GitHub Pages 的倉庫，用戶能夠利用該倉庫中的資料建立 Web 頁，用來發布倉庫中軟件的相關信息。若是已經建立過GitHub Pages，則會顯示相應 URL。點擊 Automatic Page Generator 便可以自動建立 GitHub Pages。

Collaborators

用戶主要在這裏設置倉庫的訪問權限。若是倉庫隸屬於我的帳戶，那麼能夠添加 GitHub 的用戶名，賦予該用戶直接讀寫倉庫的權限。不過，若是倉庫隸屬於 Organization 帳戶，則須要像所示的那樣先建立 Team，而後賦予該 Team 讀寫倉庫的權限。像這樣使用 Organization 帳戶能夠高效地設置倉庫權限，在公司等多人共同進行開發的組織中，建議使用 Organization 帳戶。

Webhooks & Services

在這個頁面中，用戶能夠添加 Hook 讓 GitHub 倉庫與其餘服務集成。經過 Add webhook 能夠添加用戶本身的 webhook。經過 Configureservices 則能夠從 GitHub 事先列出的能夠集成的服務中進行選擇。能與GitHub 集成的服務很是多，其中還包括郵件及 IRC 等社交服務。

Deploy Keys

在這個頁面中，用戶能夠添加用於部署的公開密鑰，容許以只讀方式訪問倉庫。設置公開密鑰後，用戶可使用私有密鑰經過 ssh 協議 clone 倉庫。要注意的是，這裏添加的公開密鑰·私有密鑰對沒法再添加到其餘倉庫。使用 Deploy Keys 功能時，須要給每一個倉庫賦予不一樣的密鑰對。

Notifications

每當建立 Issue、收到評論、建立 Pull Request 等狀況發生時，咱們就會在 Notifications 中收到通知。

其餘功能

GitHub Pages

GitHub Pages 主要用於在 GitHub 上託管靜態 HTML，以便發佈項目的 Web 頁。能夠綁定獨立域名。常被使用爲靜態博客。

GitHub Enterprise

GitHub Enterprise 專爲那些沒法將源代碼放到公司以外的企業設計。這項服務能夠以虛擬機的形式提供 GitHub。

GitHub API

GitHub 面向開發者公開了 API。

Gist

Gist 是一款簡單的 Web 應用程序，常被開發者們用來共享示例代碼和錯誤信息。它使用JavaScript 編寫的 Ace 編輯器，只需打開瀏覽器即可編寫簡單代碼。另外，Gist 中的文檔都在版本管理系統的管理之下，用戶能夠放心編輯。並且因爲其版本歷史記錄保管在 Git 倉庫中，因此還能夠經過clone 操做將 Gist 獲取至本地。共享 Gist 的人之間可以互相添加評論，全部交流都會被記錄下來。Gist 支持多種語言的語法高亮，能夠大幅加強代碼可讀性。能夠說，這一工具就是專爲程序員設計的。