一、Issue

在軟件開發過程中，開發者們爲了跟蹤BUG及進行軟件相關討論，進而方便管理，創建了Issue。管理Issue的系統稱爲BTS（Bug Tracking System，BUG跟蹤系統）。當今具有代表性的BTS有RedmineA、TracB、 Bugzilla（http://www.bugzilla.org/）等
GitHub 也爲自身加入了 BTS 的功能。在 GitHub 上，可以將它作爲軟件開發者之間的交流工具，多多加以利用。遇到下面幾種情況時，各位就可以使用這個功能：
- 發現軟件的 BUG 並報告
- 有事想向作者詢問、探討
- 事先列出今後準備實施的任務
Issue除BUG管理之外還有許多其他用途。在軟件開發者的圈子中，將Issue用於多種用途的情況已經司空見慣。作爲GitHub的功能之一，想必今後會有更多人自然而然地用到它。所以藉此機會，讓我們來共同學習Issue的一些簡單用法

新建Issue

在倉庫中點擊“Issue”，然後點擊“New issue”就可以新建一個話題

點擊“New issue”之後如下所示

簡潔且表現力豐富的描述方法

GitHub 的Issue及評論可以使用GFM(https://help.github.com/articles/github-flavored-markdown)語法進行描述，從而獲得豐富的表現力

比如像下面左圖中那樣描述，然後點擊Preview，就可以看到下面右圖那種標記後的效果

點擊文本框下面就可以找到GFM語法相關幫助的鏈接

語法高亮：假設我們像下面左圖所示，先指定語言再描述代碼，這樣一來，代碼就會如下面右圖所示被添加語法高亮，變得直觀易讀

添加圖片：添加圖片也十分簡單。只需將圖片拖曳到文本框中便可以粘貼圖片，或者選擇下圖中的鏈接會彈出對話框讓你選擇文件。GitHub的網站上也有相關內容的詳細講解，各位不妨參考一下(https://help.github.com/articles/issue-attachments)

添加標籤以便整理

Issue可以通過添加標籤（Label）來進行整理。在創建一個Issue話題時，可以爲該話題設置一個標籤，在下圖左側選擇

例如在此處我們選擇Bug

然後點擊“Submit new issue”提交之後，就會話題旁邊就會顯示這個標籤

標籤可以自由創建。既可以按語言和技術分類，也可以按照 BUG、任務、備忘等作業類型分類。各位可以按照需要選擇便於整理的標籤。

提個小建議：其實在 Issue 比較少的情況下不必每個都添加標籤，大可等 Issue 積攢到一定數量，只有進行篩選才能清晰把握時再添加標籤

添加里程碑以便管理

除標籤外，還可以通過添加里程碑來管理Issue

點擊下圖中的“Milestones”按鈕進入

然後點擊“Create a Milestone”就可以創建一個里程碑

例如下面創建一個

然後會在倉庫中顯示

設置里程碑，就可以用Issue來管理任務

Tasklist語法

我們可以使用GFM的一項獨有功能，那就是Tasklist語法(https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments)

首先試着按下面的格式進行描述

這樣一來，這段文字就會被標記成複選列表的樣式（下圖所示）。這個複選列表可以直接勾選或者取消，不必打開Issue的編輯頁面重新編輯，十分方便，建議各位記住這個功能

通過提交信息操作 Issue

在GitHub上，只要按照特定的格式描述提交信息，就可以像一般BTS帶有的功能那樣對Issue進行操作

①在相關 Issue 中顯示提交：在Issue一覽表中我們可以看到，每一個Issue標題的下面都分配了諸如“#2、#3...#24...”的編號。只要在提交信息的描述中加入“#24”，就可以如下下圖所示，在 Issue 中顯示該提交的相關信息，使關聯的提交一目瞭然。這裏只需輕輕點擊一下便可以顯示相應提交的具體內容，在代碼審查時省去了從大量提交日誌中搜索相應提交的麻煩，非常方便

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

fixes #24

fixed #24

close #24

closes #24

closed #24

resolve #24

resolves #24

resolved #24

利用這個方法，每次提交併push 之後，就不必再大費周章地到GitHub的Issue中尋找相應 Issue 再手動 Close，省去不少麻煩

像這樣，只要按照特定的格式描述提交信息，GitHub 就會自動識別並處理，讓使用 GitHub 變得更加輕鬆。目前，很多 GitHub 之外的 BTS 也實現了這一功能，記住它絕對是有利無弊的。

將特定的Issue轉換爲Pull Request

在GitHub上，如果給Issue添加源代碼，它就會變成我們下面要講到的Pull Request。Issue與Pull Request的編號相互通用，通過GitHub的API可以將特定的Issue轉換爲Pull Request，能夠完成這一操作的hub命令會在後面文章講解。在這裏，各位只要先記住Issue與Pull Request的編號通用即可

二、Pull Request

Pull Request 是用戶修改代碼後向對方倉庫發送採納請求的功能，也是GitHub的核心功能（下圖所示）。正因爲有了這個功能，纔會讓衆多開發者輕鬆地加入到開源開發的隊伍中來

Pull Request 頁面能夠列表查看當前處於Open狀態的Pull Request。通過點擊頁面左部和上部的選項可以進行篩選和重新排列
在列表中點擊特定的 Pull Request 就會進入詳細頁面（下圖所示）。頁面上方顯示着這次是從誰的哪個分支向誰的哪個分支發送了 Pull Request

下面，我們對各個標籤（Tag）頁進行講解

Conversation

在Conversation標籤頁中，可以查看與當前Pull Request相關的所有評論以及提交的歷史記錄。人們在這裏添加評論互相探討，發送提交落實討論內容的整個過程會按時間順序列出，供用戶查看。各位在查看過程中如果有自己的想法，不妨積極地添加評論參與探討

提交日誌的右側有該提交的哈希值，點擊鏈接即可確認相應提交的詳細信息

Commits

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

Files Changed

Files Changed標籤頁中可以查看當前 Pull Request 更改的文件內容以及前後差別。標籤上的數字表示新建及被更改的文件數

默認情況下系統會將空格的不同也高亮顯示，所以在空格有改動的情況下會難以閱讀。這時只要在URL的末尾添加“?w=1”就可以不顯示空格的差別

將鼠標指針放到被更改行行號的左側，我們會看到一個加號。點擊這個加號可以在代碼中插入評論（下圖）。這樣，評論是針對哪行代碼的就一目瞭然了

三、Wiki

Wiki 是一個使用簡單的語法就能編寫文檔的功能。所有有權限的人都可以對文章進行修改，所以比較適合多人共同編寫文章的情況。創建、編輯文檔時不必另外啓動軟件，用起來十分方便，非常適合用來針對更新頻率較高的軟件進行文檔等信息方面的彙總

新建Wiki

與 Issue 和 Pull Request 相同，Wiki也支持GFM語法，所以可以輕鬆創建表現力豐富的文檔

點擊頁面右上角的 New Page 按鈕便可以創建新的Wiki頁

clone編輯

Wiki功能本身的數據也在Git中進行管理

點擊Clone URL按鈕可以將當前Wiki的Git倉庫URL複製到剪貼板中。用戶能夠通過clone操作獲取Wiki倉庫，然後在本地創建、編輯頁面，進行提交再push，便可以完成對Wiki的創建及編輯工作

例如下面是一個Wiki的實例，鏈接如下：
https://github.com/dongyusheng/git-tutorial.wiki.git

Pages標籤

在Pages標籤頁中可以列表查看Wiki頁面

例如本倉庫只有一個Wiki文章，因此Pages標籤中只有一個

側邊欄

所有Wiki頁面都可以顯示側邊欄。做法很簡單，只要創建名爲“_sidebar”的頁面即可。_sidebar頁不會顯示在Pages的頁面一覽中

點擊右側的“Add a custom sidebar”既可以創建

在編輯各頁面時頁面下部會附加Sidebar 段（下圖所示），用戶可以在這裏編輯側邊欄的內容

四、Pulse

Pulse是體現該倉庫軟件開發活躍度的功能。近期該倉庫創建了多少Pull Request或Issue，有多少人蔘與了這個倉庫的開發等，都可以在這裏一目瞭然

根據這個頁面，用戶可以判斷目前這個軟件是否正在被積極開發，或者持有倉庫修改權限的人是否在認真地進行BUG修正等維護工作。在挑選GitHub上開發的軟件時，它可以作爲一個重要的衡量標準

active pull requests

頁面中Overview的左半部分顯示了特定期間內活動過的Pull Request 數

下圖中：
0個 Pull Request

其中有0個被採納(Active Pull Requests)，0個保持Open狀態(Proposed Pull Requests)

Proposed Pull Requests將來要麼會被採納，要麼會被Close

如果想查看清單的詳細內容，只要點擊對應項即可（但是此處演示案例沒有）。Pull Request 的概要及鏈接按照合併的先後順序排列

點擊 proposed-pull-request 則可以按創建的先後順序查看 Pull Request 的概要及鏈接

通過這些信息，用戶可以瞭解該軟件最近正在開發哪些功能。如果發現對方正在進行功能擴展或者修正，不妨積極試用一下這個功能。這或許會成爲您加入開源軟件開發的契機

active issue

頁面中 Overview 的右半部分顯示了特定期間內活動過的Issue數

下圖中：
有2個Issue，其中有1個被 Close，其餘1個仍處於 Open 狀態

如果想查看清單的詳細內容，只要點擊對應項即可。Issue的概要及鏈接按照 Close 的先後順序排列

點擊 new issue 則可以按創建的先後順序查看 Issue 的概要及鏈接

通過觀察 Issue 的整體動向，用戶能夠知道這個軟件是否有人在積極地維護與支持。對方倉庫越是活躍，用戶發送的 BUG 報告和相關探討越可能收到迴應

commits

Overview下方顯示的是與提交相關的信息

左側部分包含了如下幾類信息：
編寫過代碼的人數

提交的次數

default branch 中修改過的文件數

default branch 中添加的行數

default branch 中刪除的行數

通過這些信息，用戶可以大致把握該倉庫中活躍開發者的人數

另外，右側圖表顯示了這些開發者具體發送的提交數。通過圖表我們可以瞭解到有哪些開發者在格外積極地向該倉庫發送提交

五、Graphs

Insights頁中，可以通過多種圖表查看該倉庫的相關統計信息。利用圖表直觀地彙總信息，可以讓用戶把握當前倉庫的各種趨勢

Contributors

在Contributors的圖表中，我們可以看到每個用戶在相應日期中發送提交、添加代碼、刪除代碼的大致數量

從這裏我們能夠瞭解到該倉庫的代碼主要由哪些人編寫。而且，還可以通過圖表分析出該軟件大幅修改階段和穩定維護階段的相應時期

另外，這些圖表的統計中還包括髮送 Pull Request 被採納後產生的代碼增減

Commit Activity

Commit Activity 中顯示了一年內（52 周）每週收到的提交的大致數量

第二張表中還可以查看相應周每天的提交數量。判斷某個倉庫是否有人在積極更新時，這部分是一個重要的指標

Code Frequency

Code Frequency中顯示了該倉庫中代碼行數的增加量和刪除量

一款優秀的軟件並不會一味地增加代碼，在經過重構之後，代碼量往往會降低。通過這張圖，我們可以直觀地把握相應信息

Network

以圖表形式顯示包括克隆倉庫在內的所有分支的提交。從圖上可以直觀地看出每個人做了多少工作

將鼠標指針停留在表中提交或合併的點上，可以查看相應的參考內容

六、Settings

在這裏可以對倉庫進行任何設置。用戶必須擁有更改設置的權限，才能看到這個頁面

Options

①Settings：
在這裏可以修改倉庫名稱

上傳社會預覽：上傳一張圖片，定製你的存儲庫的社交媒體預覽

②Features：這裏可以更改Wiki 和 Issue 的相關設置。如果想關閉某些功能，只要取消已勾選的相應複選框，該功能就會從菜單中移除，無法使用

③GitHub Pages：
GitHub有一個名爲GitHub Pages的倉庫，用戶可以利用該倉庫中的資料創建Web頁，用來發布倉庫中軟件的相關信息。如果已經創建過GitHub Pages，則會顯示相應URL

GitHub Pages 主要用於在GitHub上託管靜態 HTML，以便發佈項目的 Web 頁(https://pages.github.com/)

由於可以綁定獨立域名，人們也經常利用結合了這個功能的 OctopressB 框架來搭建博客。有興趣的讀者不妨試一試

④Danger Zone：這裏都是一些需要格外留意的設置。在這裏，用戶可以將倉庫改爲私有或是變更倉庫所有者，甚至刪除倉庫本身。這些設置有可能影響到其他人，在變更時一定要謹慎

②Branches

功能分別爲：
設置顯示倉庫 URL 時默認顯示的分支。這個默認分支同時也是創建 Pull Request 時的默認值，如果各位的主分支不是 master 分支，建議更改這一設置

分支保護規則。定義分支保護規則來禁用強制推送，防止分支被刪除，並在合併之前有選擇地要求檢查狀態

③Webhooks

在這個頁面中，用戶可以添加Hook讓GitHub倉庫與其他服務集成。通過 Add webhook 可以添加用戶自己的 webhook

④Deploy Keys

在這個頁面中，用戶可以添加用於部署的公開密鑰，允許以只讀方式訪問倉庫。設置公開密鑰後，用戶可以使用私有密鑰通過 ssh 協議 clone 倉庫

要注意的是，這裏添加的公開密鑰·私有密鑰對無法再添加到其他倉庫。使用Deploy Keys功能時，需要給每個倉庫賦予不同的密鑰對

Notifications

第一次點進去時，會讓你設置電子郵件地址，以便在觸發推送事件時接收通知

每當創建 Issue、收到評論、創建 Pull Request 等情況發生時，我們就會在 Notifications 中收到通知

Github:10---Github功能之（倉庫頁功能介紹：Issue、Pull Request、Wiki、Pulse、Graph、Settings）

一、Issue

新建Issue

簡潔且表現力豐富的描述方法

添加標籤以便整理

添加里程碑以便管理

Tasklist語法

通過提交信息操作 Issue

將特定的Issue轉換爲Pull Request

二、Pull Request

Conversation

Commits

Files Changed

三、Wiki

新建Wiki

clone編輯

Pages標籤

側邊欄

四、Pulse

active pull requests

active issue

commits

五、Graphs

Contributors

Commit Activity

Code Frequency

Network

六、Settings

Options

②Branches

③Webhooks

④Deploy Keys

Notifications