原文連結
1 在 GitHub.com 編輯程式碼
我將從我認為大家都知道的一件事情開始(儘管我是直到一週前才知道)。
當你在 GitHub 檢視檔案時(任何文字檔案，任何倉庫中)，右上角會有一個小鉛筆圖示，點選它就可以編輯檔案了。完成之後點選 Propose file change 按鈕 GitHub 將會自動幫你 fork 該專案並且建立一個 pull request 。
很厲害吧！他自動幫你 fork 了該 repo。
不再需要 fork , pull ,本地編輯再 push 以及建立一個 PR 這樣的流程了。
這非常適合修復編寫程式碼中出現的拼寫錯誤和修正一個不太理想的想法。
2 貼上圖片
你不僅僅受限於輸入文字和描述問題，你知道你可以直接從貼上板中貼上圖片嗎？當你貼上時，你會看到圖片已經被上傳了(毫無疑問被上傳到雲端)之後會變成 Markdown 語法來顯示圖片。
3 格式化程式碼
如果你想寫一段程式碼，你可以三個反引號開始 —— 就像你在研究MarkDown時所學到的 —— 之後 GitHub 會試著猜測你寫的語言。
但如果你寫了一些類似於 Vue, Typescript, JSX 這樣的語言，你可以明確指定得到正確的高亮。
注意第一行中的
```jsx複製程式碼
這意味著程式碼段將會呈現出:
(這個擴充套件於 gists 。順便說一句，如果你使用 .jsx 字尾，就會得到JSX的語法高亮)
這是一個所有受支援的語法列表。
4 在 PR 中用關鍵詞關閉 Issues
假設你建立了一個用於修復 Issues #234 的 PR ,你可以在你 PR 的描述中填寫 fixes #234 (或是在你 PR 任意評論中填寫都是可以的)。
之後合併這個 PR 時將會自動關閉填寫的 Issues。怎麼樣,很 cool 吧。
瞭解是更多相關的內容。
5 連結到評論
你是否有過想要連結到特殊 comment 的想法但卻無法實現？那是因為你不知道怎麼做。朋友那都是過去式了，現在我就告訴你，點選使用者名稱旁邊的日期/時間即可連結到該 comment 。
6 連結到程式碼
我知道你想連結到具體的程式碼行上。
嘗試:檢視檔案時，點選程式碼旁邊的行號。
看到了吧，瀏覽器的 URL 已經被更新為行號了。如果你按住 shift,同時點選其他行號，URL 再次被更新，並且你也高亮顯示頁面中的一段程式碼。
分享這個 URL ，訪問時將會連結到該檔案已經選中的那些程式碼段。
但等一下，那指向的是當前的分支，如果檔案發生了改變呢？也許一個在當前狀態連線到檔案的永久連線正是你想要的。
我很懶，所以用一張截圖展示以上的所有操作。
談到網址。。。
7 像命令列一樣使用 GitHub 連結
使用 GitHub 自帶的 UI 瀏覽也還不錯，但有時直接在 URL 中輸入是最快的方法。比如，我想跳轉到我正在編輯的分支並和 master 進行對比，就可以在專案名稱後面接上 /compare/branch-name 。
與選中分支的對比頁將會顯示出來:
以上就是和 master 分支的差異，如果想要合併分支的話，只需要輸入 /compare/integration-branch...my-branch 即可。
你還可以利用快捷鍵達到同樣的效果，使用 ctrl + L 或者 cmd + L 可以將游標移動到 URL 上(至少在 Chrome 中可以)。 加上瀏覽器的自動補全 —— 你就可以在兩個分支之間輕鬆切換了。
8 在Issues建立列表
你想在你的 issue 中看到核取方塊列表嗎?
你想在檢視 issue 列表是它們以好看的 2 of 5 進度條呈現嗎？
太好了！你可以用以下語法來建立一個互動性的核取方塊:
- [ ] Screen width (integer)
- [x] Service worker support
- [x] Fetch support
- [ ] CSS flexbox support
- [ ] Custom elements複製程式碼是由一個空格、中橫線、空格、左括號、空格(或者是 X )、右括號、空格以及一些文字組成。
你甚至可以真正的 選中/取消 這些核取方塊！基於某些原因，對於我來說你看起來像是技術魔力。是真的能夠選中這些核取方塊！甚至它還更新了底層原始碼。
ps：以下包括第九點 基於GitHub的專案皮膚 由於用的不多就沒有翻譯。
10 GitHub wiki
作為一個像維基百科那樣的非結構化的頁面集合， GitHub Wiki的供給(我把它稱之為 Gwiki ) 是一個非常棒的功能。
對於結構化的頁面來說 —— 例如你的文件：不能說這個頁面是其他頁面的子頁面，或則是有 “下一節”，“上一節” 這樣的便捷按鈕。並且 Hansel 和 Gretel 也沒有，因為結構化頁面並沒有 breadcrumbs 這樣的設計。
我們繼續，讓 Gwiki 動起來，我從 NodeJS 的文件中複製了幾頁來作為 wiki 頁面。然後建立了一個自定義側邊欄，幫助我更好地模擬一些實際的目錄結構。儘管它不會突出顯示你當前的頁面位置，但側邊欄會一直存在。
這些連結需要你手動維護，但總的來說，我認為它可以做得很好。 如果需要的話可以看看。
雖然它與 GitBook ( Redux 文件所使用的)或者是定製網站相比仍有差距。但在你的 repo 中它有 80% 完全值得信賴的。
我的建議是: 如果你已經有多個 README.md 檔案，並且想要一些關於使用者指南或更詳細的文件的不同的頁面，那麼你應該選擇 Gwiki。
如果缺乏結構化/導航開始讓你不爽的話，那就試試其他的吧。
11 GitHub Pages
你可能已經知道使用 GitHub Pages 來託管一個靜態網站。如果你不知道，現在就來學習，這一節是專門用於討論使用 Jekyll 來構建一個站點的。
最簡單的就是： GitHub Pages + Jekyll會通過一個漂亮的主題來渲染你的 README.md 檔案。例如:通過 about-github 來檢視的我的 README 頁面。
如果我在 GitHub 中點選了 settings選項，切換到 Github Pages 設定，然後選擇一個 Jekyll theme。。。
我就可以得到 Jekyll-themed 頁面。
從這點上我可以主要依據易編輯的 Markdown 檔案來構建一個完整的靜態站點。本質上是把 GitHub 變成了 CMS。
雖然我沒有實際使用過，但是 React Bootstrap 的網站都是使用它來構建的。所以它不會糟糕。
注意:它要求 Ruby 執行本地環境( Windows 自行安裝， macOS 自帶)。
12 把 GitHub 當做 CRM 使用
假設你有一個存有一些文字內容的網站，你不想將文字內容儲存於真正的 HTML 原始碼中。
相反的，你想要將這些文字塊儲存於非開發人員能輕鬆的進行編輯的地方。可能是一個版本控制系統，甚至是一個稽核流程。
我的建議是:使用 GitHub 廠庫中的 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)}} />
);
}
}複製程式碼獎勵環節 —— GitHub 工具
我已經使用了 Octotree Chrome extension 有段時間了，現在我向大家推薦它！
無論你是在檢視哪個 repo 它都會在左側給你一個樹狀皮膚。
通過這個視訊我瞭解到了 octobox，它是用於管理你的 GitHub Issues 收件箱，看起來相當不錯！
以上就是我針對於octobox的全部想法。
其他
就是這樣了！我希望這裡至少有三件事是你還不知道的。
最後: hava a nice day！
個人部落格：crossoverjie.top。
