原文連結
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 清單是它們以好看的
2of5
進度條呈現嗎？
太好了！你可以用以下文法來建立一個互動性的複選框:
- [ ] Screen width (integer)
- [x] Service worker support
- [x] Fetch support
- [ ] CSS flexbox support
- [ ] Custom elements 複制
是由一個空格、中橫線、空格、左括号、空格(或者是 X )、右括号、空格以及一些文本組成。
你甚至可以真正的 選中/取消 這些複選框！基于某些原因，對于我來說你看起來像是技術魔力。是真的能夠選中這些複選框！甚至它還更新了底層源碼。
ps：以下包括第九點 基于GitHub的項目面闆 由于用的不多就沒有翻譯。
10 GitHub wiki
作為一個像維基百科那樣的非結構化的頁面集合，
GitHubWiki
的供給(我把它稱之為
Gwiki
) 是一個非常棒的功能。
對于結構化的頁面來說 —— 例如你的文檔：不能說這個頁面是其他頁面的子頁面，或則是有 “下一節”，“上一節” 這樣的便捷按鈕。并且
Hansel
和
Gretel
也沒有，因為結構化頁面并沒有
breadcrumbs
這樣的設計。
我們繼續，讓 Gwiki 動起來，我從
NodeJS
的文檔中複制了幾頁來作為 wiki 頁面。然後建立了一個自定義側邊欄，幫助我更好地模拟一些實際的目錄結構。盡管它不會突出顯示你目前的頁面位置，但側邊欄會一直存在。
這些連結需要你手動維護，但總的來說，我認為它可以做得很好。 如果需要的話可以看看。
雖然它與
GitBook
( Redux 文檔所使用的)或者是定制網站相比仍有差距。但在你的 repo 中它有 80% 完全值得信賴的。
我的建議是: 如果你已經有多個
README.md
檔案，并且想要一些關于使用者指南或更詳細的文檔的不同的頁面，那麼你應該選擇
Gwiki
。
如果缺乏結構化/導航開始讓你不爽的話，那就試試其他的吧。
11 GitHub Pages
你可能已經知道使用
GitHubPages
來托管一個靜态網站。如果你不知道，現在就來學習，這一節是專門用于讨論使用
Jekyll
來建構一個站點的。
最簡單的就是：
GitHubPages+Jekyll
會通過一個漂亮的主題來渲染你的
README.md
檔案。例如:通過 about-github 來檢視的我的
README
頁面。
如果我在 GitHub 中點選了
settings
選項，切換到
GithubPages
設定，然後選擇一個
Jekylltheme
。。。
我就可以得到 Jekyll-themed 頁面。
從這點上我可以主要依據易編輯的
Markdown
檔案來建構一個完整的靜态站點。本質上是把 GitHub 變成了
CMS
。
雖然我沒有實際使用過，但是
ReactBootstrap
的網站都是使用它來建構的。是以它不會糟糕。
注意:它要求
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，它是用于管理你的
GitHubIssues
收件箱，看起來相當不錯！ 以上就是我針對于
octobox
的全部想法。
其他
就是這樣了！我希望這裡至少有三件事是你還不知道的。
最後: hava a nice day！
感謝好基友的校對。