GitHub 的 12 個驚人功能

對於我的生活，我想不出任何介紹，所以......

#1 在 GitHub.com 上編輯程式碼

我將從我認為每個人都已經知道的內容開始（儘管我個人一周前對此一無所知）。在任何儲存庫中查看 GitHub 上的任何文字檔案時，您都可以在右上角看到一支小鉛筆。如果單擊它，您可以編輯該文件。完成後，按一下“建議檔案變更”，GitHub 將建立一個分叉和拉取請求。太棒了，不是嗎？他自己創造了叉子！無需 fork 程式碼並將其上傳給自己、在本地進行更改並透過 Pull 請求將其發送回 GitHub。如果您需要進行最少的編輯，則非常方便。 不完全是真正的 Pull 請求

#2 插入影像

問題描述不僅限於文字註釋。您知道可以直接從剪貼簿貼上影像嗎？貼上後，您會看到它已上傳（毫無疑問，上傳到雲端）並轉換為標記來顯示圖像。優美！

#3 代碼格式化

如果您需要編寫一段程式碼，請從三個反引號開始，GitHub 將嘗試猜測您正在使用哪種程式語言編寫。但是，如果您使用 Vue、Typescript 或 JSX 等程式語言發佈一段程式碼，則可以明確指定語言，以便語法反白顯示正確。注意第一行的``jsx： ....確保程式碼片段的正確顯示： （順便說一句，這也適用於 Gist。如果為 gist 指定 .jsf 副檔名，則 JSF 語法將被反白）。以下是所有支援的語法的清單。

#4 在 Pull 請求中使用「魔法詞」來解決問題

假設您建立了一個修復問題 #234 的 Pull 請求。您可以將文字「fixes issues #234」插入到您的請求描述中（或任何變更請求註釋中的任何位置）。此後，合併 Pull 請求將「自動」解決問題。很酷，不是嗎？文件中提供了有關此內容的更多資訊。

#5 評論鏈接

您是否曾經需要建立指向特定評論的連結但不知道如何操作？那些日子已經一去不復返了，因為我將告訴您一個秘密：要創建評論鏈接，您只需單擊標題旁邊的日期/時間即可。 看，加隆現在有照片了！

#6 程式碼連結

因此您想要建立指向特定程式碼行的連結。在這種情況下，請嘗試以下操作：在開啟的檔案中按一下所需程式碼旁邊的行號。哇，看到了嗎？URL 已更改，行號現在可見！如果您按住 SHIFT 鍵並點擊另一個行號，那麼瞧！– URL 將再次更改，並且行範圍將突出顯示。該 URL 現在將指向該文件和該範圍的行。但是等等，它指向當前執行緒。如果文件改變了怎麼辦？在這種情況下，您可能需要一個指向當前狀態的文件的永久連結。我很懶，所以把上面的都截圖了： 順便說一下，關於 URL...

#7 使用 GitHub URL 作為命令列

使用 UI 瀏覽 GitHub 非常方便。但有時，要存取特定位置，只需將其輸入 URL 會更快。例如，如果我想轉到我正在處理的分支並查看它與主分支的比較，我可以簡單地 在儲存庫名稱後輸入/compare/branchname 。這將帶我進入該分支的差異頁面： 但這些與 master 分支不同，但如果我之前使用過整合分支，我可以在 URL 中輸入/compare/integration-branch...my-branch 對於熱鍵愛好者：CTRL+L 或 CMD+L 將遊標移至 URL 欄（至少在 Chrome 和 Firefox 瀏覽器中）。這與瀏覽器自動完成功能相結合，使得分支之間的導航變得更加容易。 專業提示：使用箭頭瀏覽 Chrome 的自動完成建議，然後按 SHIFT+DELETE 從歷史記錄中刪除項目（例如，合併分支後）。（我不知道如果我在其中放一個空格，例如 SHIFT + DELETE，是否會更容易閱讀這些快捷鍵。但從技術上講，“+”不是它們的一部分，所以我不喜歡這個選項。它是因為這樣的事情我晚上睡不著覺，朗達。）

#8 建立問題列表

您想要在問題描述中新增複選框嗎？ 當您從清單中查看問題時，您是否希望出現像“5 分之二”這樣的漂亮欄？ 沒問題！您可以使用以下語法建立互動式複選框：

• [ ] 螢幕寬度（整數）
• [x] 服務人員支持
• [x] 獲取支持
• [ ] CSS 彈性盒支持
• [ ] 自訂元素

語法：空格、連字符、空格、左方括號、空格（或 x）、右方括號、空格和一些單字。之後，您實際上可以選取/取消選取這些按鈕！出於某種原因，這對我來說似乎是某種技術魔法。您可以勾選方框！同時原文也發生了變化！想想他們接下來會想出什麼就很可怕。哦，如果這個問題出現在專案面板中，那麼進度也會顯示在那裡： 如果您不明白我所說的“項目面板”的意思 - 請閱讀下文。此頁面僅低幾公分。

#9 GitHub 中的專案面板

對於大型項目，我一直使用 Jira。對於我的個人項目，我一直使用 Trello。我真的很喜歡這兩個工具。幾週前，當我得知 GitHub 在儲存庫的「專案」標籤中提供了自己的選項時，我認為複製我已經在 Trello 中處理的任務集是有意義的。 這裡沒什麼好笑的。現在 GitHub 專案中也出現了同樣的情況： 漸漸地，您的眼睛會習慣低對比影像 為了速度起見，我將上述所有內容添加為註釋，這意味著它們不是「真正的」GitHub 問題。但 GitHub 中問題管理的強大之處在於它與儲存庫的其餘部分的整合 - 因此最好將儲存庫中的現有問題添加到儀表板。按一下右上角的「新增卡片」 ，然後找到您要新增的內容。這就是特殊搜尋語法派上用場的地方：例如，輸入is:pr is:open，您可以將任何開啟的 Pull 請求拖曳到面板上，或者如果需要修復任何錯誤，請 輸入 label:bug 。 您也可以將現有筆記轉換為問題。 最後，從現有的問題表單中，將其新增至右側面板中的項目。 它將進入該項目面板的分類列表，因此您可以選擇將其放入哪一列 當「任務」的描述與實現該任務的程式碼位於同一儲存庫中時，這是非常（非常）方便的。這意味著從現在起很多年後，您將能夠在一行程式碼上運行gitblame並找出導致該行的全部問題，而無需在 Jira/Trello/其他地方進行全部追蹤。

缺陷

在過去的三週裡，我一直在嘗試在 GitHub 而不是 Jira 中完成所有操作（在一個小專案上，有點看板風格），並且喜歡它。但對於需要正確評估和計算開發速度等的 Scrum 項目，我無法想像這一點。好消息是 GitHub 專案的「特殊功能」很少，切換到另一個系統不會花費太多時間。因此，嘗試一下，看看您有多喜歡它。我不知道這有多重要，但我聽說了ZenHub，並在 10 分鐘前第一次打開它。它本質上是 GitHub 的擴展，您可以在其中對問題進行評級並創建“史詩”和依賴項。有發展速度和倦怠的圖表；看起來這簡直就是一件了不起的事。進一步閱讀：有關專案的 GitHub 文件。

#10 維基百科

對於像 Wikipedia 這樣的非結構化頁面集，GitHub Wiki（從現在起我將其稱為 Gwiki）非常有用。對於一組結構化頁面 - 例如，像您的文件 - 沒有那麼多。沒有辦法表明「這個頁面是那個頁面的子頁面」；沒有像「下一節」和「上一節」按鈕這樣方便的東西。Hansel 和 Gretel 肯定會在這裡迷路，因為這裡也沒有“麵包屑”（特殊的調試運算符 - 大約反式）。（作者註：你讀過這個故事嗎？這太不人道了。兩個年輕的暴徒殺死了一位可憐的飢餓老太太，把她活活燒死在自己的烤箱裡。當然，留下了一片狼藉，沒有人能理解。我想這就是為什麼現在的年輕人太敏感了——現在在睡前給孩子們講故事還不夠殘酷！）繼續——為了真正嘗試Gwiki，我從NodeJS 輸入了一些頁面作為wiki 頁面，然後建立了一個自訂頁面側邊欄模擬網站的實際結構。儘管當前頁面未突出顯示，但該側邊欄始終存在。連結必須手動維護，但總體而言一切正常。如果你願意的話，你可以看一下： 這很難與 GitBook（ Redux文件中使用的）或定製網站之類的東西競爭。但這已經是其中的 80%，而且您的儲存庫中的所有內容都正確。我只是這個的粉絲。我建議，如果您已經無法滿足單個 README.md 文件的需求，並且需要多個不同的頁面來獲取用戶手冊或更詳細的文檔，那麼堅持使用 Gwiki 是有意義的。如果缺乏結構/導航讓您感到困擾，請繼續做其他事情。

#11 GitHub 頁面

您可能已經知道 GitHub Pages 可用於託管靜態網站。如果你不知道，那你現在知道了。然而，本節專門討論一個更具體的主題：使用Jekyll建立網站。最簡單的形式是，GitHub Pages + Jekyll 可以使用漂亮的主題呈現 README.md 檔案。例如，查看about-github中的我的自述文件頁面： 如果您按一下此 GitHub 網站的設定選項卡，請啟用 GitHub Pages，然後選擇 Jekyll 主題... 然後我們會得到一個 Jekyll 主題風格的頁面： 然後，您可以主要基於可輕鬆編輯的標記檔案來建立整個靜態站點，從本質上將 GitHub 轉變為 CMS。雖然我沒有實際使用過這個，但這就是使用 React 的 Bootstrap 框架建立網站的方式，所以沒有什麼可怕的。我注意到Ruby必須運行在本地機器上（這裡的Windows用戶會交換一個了解的眼神然後走另一條路，macOS用戶會說：「有什麼問題，你要去哪裡？Ruby是一個通用平台！還有一個GEMS”套件管理系統！”）（也值得注意的是，GitHub Pages 上不允許出現“攻擊性或威脅性內容或行為”，因此您將無法在那裡發布 Hansel 和 Gretel 故事的版本）。

我的想法

我對 GitHub Pages + Jekyll 組合（針對本文）研究得越多，就越覺得整個想法聽起來很奇怪。「用最少的努力製作自己的網站」的想法很棒。但要使用它，您仍然需要本機上的當前版本。對於如此“簡單”的東西，有太多的命令列命令。我瀏覽了入門部分的七頁，感覺唯一簡單的就是我自己。我什至還沒有弄清楚主頁的簡單語法或簡單的“基於 Liquid 語言的模板機制”的基礎知識。我寧願自己寫一個網站！老實說，我有點驚訝 Facebook 將其用於 React 文檔，因為他們可能每天都可以使用 React 構建幫助系統頁面並預先渲染為靜態 HTML 文件。他們所需要做的就是找到一種方法來接收現有標記文件，就像它們來自 CMS 一樣。如果什麼...

#12 使用 GitHub 作為 CMS

假設我們有一個包含一些文字的網站，但我們不想將該文字儲存為 HTML 標記。相反，我們希望將文字區塊儲存在非開發人員使用者可以輕鬆編輯的地方。最好有一些版本控制選項。也許甚至有某種同儕審查過程。這是我的建議：使用儲存在儲存庫中的標記檔案來儲存文字。並在客戶端使用一個元件來檢索這些文字並將其顯示在頁面上。我是 React 的粉絲，所以這裡有一個正確的 <Markdown> 元件的範例，給定 Markdown 檔案的路徑，它將提取它、解析它並將其呈現為 HTML。

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      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)}} />
      );
    }
}

（我在這裡使用 npm標記的套件來解析 HTML 中的標記）URL 指向我的範例儲存庫，其中包含/text-snippets目錄中的標記檔案。（您也可以使用 GitHub 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>
);

因此，現在 GitHub 在某種程度上充當了您想要託管的那些文字片段的 CMS。上面的範例僅在元件載入到瀏覽器後檢索標記。如果您需要靜態站點，則必須將其呈現在伺服器上。好消息！沒有什麼可以阻止您檢索伺服器上的所有標記檔案（使用您喜歡的任何快取策略）。如果您決定走這條路，那麼使用 GitHub API 來取得目錄中所有標記檔案的清單是有意義的。 獎勵 - GitHub 實用程式！我已經使用Octotree Chrome 擴充功能有一段時間了，並向您推薦它。並非毫無保留，但我仍然推薦它。它在左側顯示一個面板，其中包含您正在瀏覽的儲存庫的樹視圖。 從這個影片中我了解了octobox，到目前為止，在我看來它也是一個非常好的實用程式。這是您的 GitHub 問題的收件匣。這就是你需要了解的關於他的一切。說到顏色，我以淺色主題拍攝了以上所有螢幕截圖，以免嚇到您。但如果我更喜歡其他一切的深色，那麼為什麼要忍受死色蒼白的 GitHub？ 這裡我使用了 Chrome 瀏覽器的Stylish擴充功能（可以將主題套用到任何網站）和GitHub Dark風格的組合。對於初學者來說，GitHub 開發人員工具深色主題（內置，您只需啟用它）和Chrome 的Atom One Dark主題。

位元桶

嚴格來說，這裡並不完全合適，但我就是忍不住要提一下 Bitbucket。兩年前，我開始了一個項目，花了半天選擇最好的 git 託管。因此，Bitbucket 以大幅優勢獲勝。他們的程式碼審查流程遠遠領先競爭對手（這早在 GitHub 有了審查者的概念之前）。此後，GitHub 也獲得了評論。不幸的是，去年我沒有機會使用 Bitbucket - 也許他們在某些方面再次取得了進展。所以我建議負責選擇 git 託管服務的人也要關注 Bitbucket。

結論

就這樣！我希望我能夠告訴您至少三件您以前不知道的事情。我也希望您在閱讀我的文章時感到愉快。