【譯】你能夠用GitHub作的12件 Cool 事情

原文連接

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。