GitHub 12個小技巧
1. 在 GitHub.com 上編輯程式碼
我要從一個我認為大多數人都知道的功能（即使一週之前我不知道）開始。
當你在 GitHub 中檢視檔案（任何文字檔案、任何倉庫）時，右上角都會呈現一個鉛筆圖示。 點選它即可編輯該檔案。 編輯完成之後，點選“Propose file change”按鈕，GitHub 將為你 fork 程式碼倉庫併發起 pull request。
是不是很厲害？自動替你 fork 程式碼。
不需要自己手動將程式碼 fork 到本地，然後進行 pull、修改、push、pull request 等一系列操作。
這對於修復拼寫錯誤和程式碼的 bug 非常方便。
2. 貼上圖片
你不僅僅限於評論和問題說明中的文字。 你還可以直接從剪貼簿貼上圖片。 當你貼上時，就會看到推按被上傳到雲端，並在 markdown 中整齊的顯示出來。
3. 格式化程式碼
如果你想編寫程式碼塊，你可以從三個反引號開始 - 就像你在閱讀 Mastering Markdown頁面時學到的一樣，而 GitHub 會自動識別你正在使用的程式語言種類。
但是，如果你提交類似 Vue、Typescript 或者 JSX 這樣的程式碼片段時，你可以明確指定語言種類以獲取正確的突出顯示。
請注意第一行中的 “`jsx：
這樣的結果就意味著程式碼片段呈現正確：
（這擴充套件到 gists，順便說一句，如果你給 gist 一個 .jsx 的副檔名，那麼將可以得到 JSX 語法高亮。）
4.在 PR 中使用魔術詞關閉 issue
假設你正在建立一個解決問題 ＃234 的 pull 請求。 你可以將文字 “fixes ＃234” 放在你的 pull 請求描述中（或者在 pull 請求的任何評論中的任何地方）。
然後，合併 pull 請求就會自動關閉這個問題。 很酷對吧？
5. 連結評論
你是否曾經想要連結到一個特定的評論，但是卻不知道如何操作？ 此時你可以告別這樣的日子了，因為我現在會告訴你點選名字旁邊的日期/時間是如何連結到評論的。
6. 連結程式碼
你是否想要連結到一個特定的程式碼行？ 我知道怎麼做。
試試這個操作：在檢視檔案時，點選所述程式碼旁邊的行號。
哇，你看到了嗎？URL 已更新為行號！ 如果你按住 Shift 鍵並單擊另一行號，很快，該 URL 將再次更新，並且高亮這兩行之間的所有程式碼段。
現在可以共享該 URL 了，但這些還是會指向當前分支。 如果檔案改變了怎麼辦？ 當前狀態下檔案的永久連結（permalink ）即可解決該問題。
我很懶，所以我在一個螢幕截圖中完成了上述所有操作：
7. 使用類似命令列的GitHub URL
使用 UI 瀏覽 GitHub 是很好的。 但是有時候，最快的方法就是在 URL 中輸入。 例如，如果我想跳轉到我正在處理的分支，並且檢視它去主分支的區別，我可以在我的 repo名稱之後鍵入/compare/分支名稱。
這將顯示當前分支與主分支的差異：
如果我正處在一個 integration 分支，我需要輸入/compare/integration-branch…名稱。
使用 ctrl + L 或 cmd + L 快捷鍵會將游標向上移動到 URL 中（至少在 Chrome 瀏覽器中是這樣）。 在加上瀏覽器的自動完成功能，使得在分支之間跳轉變得非常簡單和方便。
專業提示：使用箭頭鍵移動 Chrome 的自動完成建議，並按 Shift + delete 從歷史記錄中刪除專案（例如，一旦分支合併）。
8. 在 issue 中建立 list
你想檢視問題的複選框列表嗎？
並且當你在 list 中檢視問題時，是否希望將其顯示為“2/5”欄。
很棒！ 你可以使用如下語法建立互動式複選框：
- [ ] 螢幕寬度（整數） - [ x ]服務人員支援 - [ x ]提取支援 - [ ] CSS flexbox支援 - [ ]自定義元素
輸入內容依次是：一個空格，一個破折號，一個空格，一個左方括號和一個空格（或一個x）和一個右方括號，然後又一個空格，最後是一些描述語言。
實際上你可以選中/取消選中這些框！ 在我看來這種操作很神奇。 你可以勾選選擇框，它會根據你的選擇而更新文字顯示選項！
如果你在專案板上有這個問題，它也會顯示出來：
如果你不懂我所說的 “專案板” 是什麼意思，你可以通過下文進行了解。
9. GitHub 專案板
我一直使用 Jira 來做大專案，而對於個人專案，我一直在使用 Trello，我非常喜歡它們。
幾周之後，GitHub 有了自己的產品，就在我的倉庫的 “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 和依賴。還有速度和燃盡圖，它看起來非常強大。
進一步閱讀：GitHub 專案幫助。
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 = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';
this.state = {
markdown: '',
};
}
componentDidMount() {
fetch(`${this.baseUrl}/${this.props.url}`)
.then(response => response.text())
.then((markdown) => {
this.setState({markdown});
});
}
render() {
return (
<div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
);
}
}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
這是我的示例 repo，在 /text-snippets 中有一些 markdown 檔案。
（你也可以使用 GiHub API 獲取內容 - 但我不知道為什麼會這樣）
你會使用這樣的元件：
const Page = () => (
<div className="page">
<div className="about-us">
<Markdown url="about-us.md" />
</div>
<div className="disclaimer">
<p>A very important disclaimer:</p>
<Markdown url="disclaimers/home-page-disclaimer.md" />
</div>
</div>
);- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
所以現在，GitHub 就是你想要 CMS，用來管理你的文字塊。
上述示例僅在元件已安裝在瀏覽器中後才能獲取 markdown。 如果你想要一個靜態網站，那麼你需要伺服器對其進行渲染。
好訊息！ 沒有任何東西可以阻止你從伺服器上獲取所有的 markdown 檔案（再加上適用於你的快取策略）。 如果您沿著這條路走下去，你可能需要檢視 GitHub API 以獲取目錄中所有的 markdown 檔案的列表。
GitHub 工具
我已經使用了 Octotree Chrome 擴充套件程式一段時間了，因此我強烈推薦它。
它給你一個在左邊的面板，通過樹型檢視顯示你正在看的 repo。
從這個視訊我知道了 octobox，到目前為止似乎相當不錯。 這是你的 GitHub 的問題收件箱。 必須推薦。
說到顏色，我把我的所有螢幕截圖放在了輕主題中，以免讓你吃驚。 但是真的，我看到的一切都是黑暗的主題，為什麼要忍受一個蒼白的 GitHub？
這是 Stylish Chrome擴充套件程式（可以將主題應用到任何網站）和 GitHub Dark 風格的組合。為了完成外觀，可以使用 Chrome DevTools 的黑色主題（內建的，在設定中開啟）和 Chrome 的 Atom One Dark 主題。