GitHub 的 12 個實用技巧，你 get 了幾個？

做者丨David Gilbertson
譯者 丨安翔
轉載來源：CSDN

1. 在 GitHub.com 上編輯代碼

我要從一個我認爲大多數人都知道的功能（即便一週以前我不知道）開始。
當你在 GitHub 中查看文件（任何文本文件、任何倉庫）時，右上角都會呈現一個鉛筆圖標。 點擊它便可編輯該文件。 編輯完成以後，點擊「 Propose file change 」按鈕，GitHub 將爲你 fork 代碼倉庫併發起 pull request。

是否是很厲害？自動替你 fork 代碼。

不須要本身手動將代碼 fork 到本地，而後進行 pull、修改、push、pull request 等一系列操做。

這對於修復拼寫錯誤和代碼的 bug 很是方便。

2. 粘貼圖片

在 Github 上不只能夠評論以及文字說明提交問題，還能夠直接從剪貼板粘貼圖片。 當你粘貼時，圖片會被上傳到雲端，並在 markdown 中整齊的顯示出來。

3.格式化代碼

若是你想編寫代碼塊，你能夠從三個反引號開始 - 就像你在閱讀 Mastering Markdown 頁面時學到的同樣，而 GitHub 會自動識別你正在使用的編程語言種類。

可是，若是你提交相似 Vue、Typescript 或者 JSX 這樣的代碼片斷時，你能夠明確指定語言種類以獲取正確的高亮顯示。

請注意第一行中的 ```jsx：

這樣的結果就意味着代碼片斷呈現正確：

（這能夠擴展到 gists，順便說一句，若是你給 gist 一個 .jsx 的擴展名，那麼將能夠獲得 JSX 語法高亮。）

瞭解全部支持的語法：github.com/github/ling…

4. 在 PR 中使用魔術詞關閉 issue

假設你正在建立一個 pull request 去修復 issue ＃234 的 pull，那麼能夠在 PR 中輸入「fixes ＃234」 ，而後就能夠自動合併 PR 並關閉該 issue。 很酷對吧？

5.連接到 comment

你是否曾經想要連接到一個特定的評論，可是殊不知道如何操做？ 此時你能夠告別這樣的日子了，由於我如今會告訴你點擊名字旁邊的日期/時間就能夠連接到評論了。

6. 連接代碼

你是否想要連接到一個特定的代碼行？ 我知道怎麼作。

試試這個操做：在查看文件時，點擊所述代碼旁邊的行號。

哇，你看到了嗎？URL 已更新爲行號！ 若是你按住 Shift 鍵並單擊另外一行號，很快，該 URL 將再次更新，而且高亮這兩行之間的全部代碼段。

如今能夠共享該 URL 了，但這些仍是會指向當前分支。 若是文件改變了怎麼辦？ 當前狀態下文件的永久連接（permalink ）便可解決該問題。

我很懶，因此我在一個屏幕截圖中完成了上述全部操做：

7. 使用相似命令行的GitHub URL

使用 UI 瀏覽 GitHub 很方便也很好。 可是有時候，最快的方法就是在 URL 中輸入。 例如，若是我想跳轉到我正在處理的分支，而且查看分支和 master 的區別，我能夠在個人 repo 名稱以後鍵入 /compare/branch-name。

這將顯示當前分支與主分支的差別：

若是我正處在一個 integration 分支，我須要輸入/compare/integration-branch...名稱。

使用 ctrl + L 或 cmd + L 快捷鍵會將光標向上移動到 URL 中（至少在 Chrome 瀏覽器中是這樣）。

在加上瀏覽器的自動完成功能，使得在分支之間跳轉變得很是簡單和方便。

專業提示：使用箭頭鍵移動 Chrome URL 上的某一條網頁記錄，並按 Shift + delete 從歷史記錄中刪除該記錄（一旦分支合併以後就能夠刪除）。

8. 在 issue 中建立 list

你想查看 issue 的複選框列表嗎？

而且當你在 list 中查看問題時，是否但願將其顯示爲「2/5」欄。

若是想， 你可使用以下語法建立交互式複選框：

• [ ] Screen width (integer)
• [x] Service worker support
• [x] Fetch support
• [ ] CSS flexbox support
• [ ] Custom elements

輸入內容依次是：一個空格，一個破折號，一個空格，一個左方括號和一個空格（或一個x）和一個右方括號，而後又一個空格，最後是一些描述語言。

實際上你能夠選中/取消選中這些框！ 在我看來這種操做很神奇。 你能夠勾選選擇框，它會根據你的選擇而更新文本顯示選項！

若是你在項目板上有這個問題，它也會顯示出來：

若是你不懂我所說的 「項目板」 是什麼意思，你能夠經過下文進行了解。

9. GitHub 項目板

我一直使用 Jira 來作大項目，而對於我的項目，我一直在使用 Trello，這兩種我都喜歡。
後來我才知道，GitHub 有了本身的 project board，就在個人倉庫的 「Project」 選項卡上，我複製一些我已經在 Trello 上開展的任務。

在 GitHub 項目中也是如此：

爲了方便，我將上述的項目都添加爲「筆記」 。可是，在 GitHub 中管理任務的功能是與倉庫的其他部分集成在一塊兒，所以你可能但願將現有問題添加到備份庫中。

你能夠點擊右上角的 Add Cards，找到要添加的內容。 此時特殊搜索語法就派上用場了，例如，輸入 is：pr is ：open 即可以將任何公開的 pull 請求拖動到項目板上，或者輸入 label：bug 便可粉碎一些 bug。

還能夠將現有筆記轉換爲問題。

也能夠在現有問題的屏幕中，將其添加到右窗格的項目裏面。

將「任務」定義與實現該任務的代碼存儲在同一個倉庫中很是有益。這意味着從此你能夠在任意一行代碼上進行 git 操做，可以根據更改記錄找回歷史代碼，無需在 Jira 或者Trello 等其餘地方進行跟蹤。

缺點：在過去三週裏我再也不使用 Jira，而是一直在 GitHub 上作全部的任務，這是一個我很喜歡的有點看板風格的小項目。

可是我沒法想象在 Scrum 項目中使用它，沒法對其進行適當的開發速度或者其餘優勢的估計和計算。

好消息是，GitHub 項目的「功能」不多，所以你不須要花很長時間來評估是否能夠切換。因此嘗試一下，看看你的想法。

無論怎樣，我據說過 ZenHub，並在 10 分鐘前首次打開了它。它有效地擴展了 GitHub，因此你能夠估計你的問題並建立 epics 和依賴。還有速度和燃盡圖，它看起來很是強大。

10. GitHub wiki

對於非結構化的頁面集合，就像維基百科，GitHub Wiki 產品（我之後將其稱爲Gwiki）是很是好的。

對於結構化的頁面集合，例如你的文檔則不是這樣。沒有辦法說「這個頁面是另外一頁面的子頁面」，也沒有諸如「下一頁」和「上一頁」這樣的導航按鈕。而 Hansel 和 Gretel 會由於沒有面包屑而受到傷害（格林童話）。

（旁註，你讀過這個故事嗎？這是殘酷的，兩個混蛋孩子們在本身的烤箱裏焚燒了這個可憐的老太太，我認爲這就是爲何青年這些天是如此敏感的緣由 - 睡衣故事如今不包含足夠的暴力。）

對 Gwiki 進行延伸，我從 NodeJS 文檔中輸入了幾頁做爲 wiki 頁面，而後建立了一個自定義側邊欄，以便我能夠模擬一些實際的結構。側邊欄在任什麼時候候都在，儘管它不突出顯示你當前的頁面。

連接必須手動維護，但總而言之，我認爲它會工做正常。若是你有須要的話能夠看看。

它不會與 GitBook（這是 Redux 文檔使用的）或定製網站等競爭。 可是它 80％ 甚至全部的權利都在你的 repo 中。

個人建議：若是你的 README.md 文件超過一個，而且須要幾個不一樣的頁面爲用戶提供指南或者更詳細的文檔，那麼你應該使用 Gwiki。

11. GitHub 頁面（Jekyll）

你可能已經知道可使用 GitHub 頁面來託管靜態網站。 若是你還不知道，能夠查看資料本身掌握。 本節會特別介紹如何使用 Jekyll 構建站點。

最簡單的是，GitHub 頁面 + Jekyll 將以漂亮的主題呈現你的 README.md。 例如，咱們能夠看一下 about-github 的 readme 頁面：

若是在 GitHub 中點擊個人網站的「設置」標籤，打開 GitHub 頁面，而後選擇一個 Jekyll主題...

我會獲得一個 Jekyll 主題頁面：

這樣我就能夠創建一個總體靜態網站，主要是圍繞能夠很容易編輯的 markdown 文件，能夠把 GitHub 轉變成 CMS。

我沒有實際使用它，可是這是 React 和 Bootstrap 網站的製做方式。

注意，它須要 Ruby 在本地運行（Windows 用戶將交換知道的視線，走向另外一個方向，macOS 用戶將會像「有什麼問題，你要去哪裏？Ruby 是一個通用平臺！GEMS！」）。

（這裏也值得一提的是，GitHub 頁面不容許使用「暴力威脅內容或活動」，所以你沒法促使 Hansel 和 Gretel 從新啓動。）

個人觀點：
我對 GitHub 頁面 + Jekyll（對於這篇文章）瞭解越多，就越感受奇怪。

「排除構建本身網站的複雜性'的想法是偉大的。可是你仍然須要一個構建設置來實現本地運行。有不少 簡單的 CLI 命令幫助你設置。

我剛剛在「入門」部分的七頁中略過，我以爲它是這裏惟一簡單的事情。並且我尚未學習簡單的「前端」語法，尚未學習簡單的「液體模板引擎」的內容。我寧願寫一個網站。

說實話，我有點驚訝 Facebook 竟然使用這個 來構建 React 文檔，他們創建 React 的幫助文檔並將其預渲染爲靜態 HTML 文件僅花了一天時間。

他們所須要作的只是定製其現有的 markdown 文件，就像它們來自 CMS 同樣。

12. 使用GitHub做爲CMS

假設你的網站中包含一些文字，但你不想將該文本存儲在實際的 HTML 標記中。

相反，你但願將文本塊存儲在某個地方，以便非開發者能夠輕鬆編輯文本。也許用某種形式的版本控制。也許是一個審查過程。

這是個人建議：使用存儲在倉庫中的 markdown 文件來保存文本。而後用你的前端組件抓取這些文本塊並將其呈如今頁面上。

我是一個 React 開發者，這裏給出一個 Markdown 組件的例子，給定一些 markdown 的路徑，獲取、解析和呈現爲 HTML。

class Markdown extends React.Component {
constructor(props) {
super(props);
// replace with your URL, obviously
this.baseUrl = 'raw.githubusercontent.com/davidgilber…';
this.state = {
markdown: '',
};
}
componentDidMount() {
fetch(${this.baseUrl}/${this.props.url})
.then(response => response.text())
.then((markdown) => {
this.setState({markdown});
});
render() {
return (
);
這是個人示例 repo，在 /text-snippets 中有一些 markdown 文件。
（你也可使用 GiHub API 獲取內容 - 但我不知道爲何會這樣）
你會使用這樣的組件：
const Page = () => (
A very important disclaimer:
);

因此如今，GitHub 就是你想要 CMS，用來管理你的文本塊。

上述示例僅在組件已安裝在瀏覽器中後才能獲取 markdown。 若是你想要一個靜態網站，那麼你須要服務器對其進行渲染。

好消息！ 沒有任何東西能夠阻止你從服務器上獲取全部的 markdown 文件（再加上適用於你的緩存策略）。 若是您沿着這條路走下去，你可能須要查看 GitHub API 以獲取目錄中全部的 markdown 文件的列表。

GitHub 工具

我已經使用了 Octotree Chrome 擴展程序一段時間了，所以我強烈推薦它。
它給你一個在左邊的面板，經過樹型視圖顯示你正在看的 repo。

從這個視頻我知道了 octobox，到目前爲止彷佛至關不錯。 這是你的 GitHub 的問題收件箱。 必須推薦。

說到顏色，我把個人全部屏幕截圖放在了輕主題中，以避免讓你吃驚。 可是真的，我看到的一切都是黑暗的主題，爲何要忍受一個蒼白的 GitHub？

這是 Stylish Chrome擴展程序（能夠將主題應用到任何網站）和 GitHub Dark 風格的組合。爲了完成外觀，可使用 Chrome DevTools 的黑色主題（內置的，在設置中打開）和 Chrome 的 Atom One Dark 主題。