你可能不知道的15個有用的Github功能

引言 🏂

咱們平時的工做中，github是必不可少的代碼託管平臺，可是大多數同窗也只是把它作爲了託管代碼的地方，並無合理的去運用。

其實github裏面有很是多好玩或者有趣的地方的。固然，這些技巧也能對你的工做效率有很大的提高。

我整理了一些本身平時用的比較多的一些功能/技巧，也但願能給你的工做帶來一些幫助！

Gist 🍓

可能不少人並無聽過Gist。它在github首頁的子目錄下：

這是github提供的一個很是有用的功能。Gist做爲一個粘貼數據的工具，就像 Pastie 網站同樣，能夠很容易地將數據粘貼在Gist網站中，並在其餘網頁中引用Gist中粘貼的數據。

做爲GitHub的一個子網站，很天然地，Gist使用Git版本庫對粘貼數據進行維護，這是很是方便的。

進入Gist網站的首頁，就會看到一個大大的數據粘貼對話框. 只要提供一行簡單的描述、文件名，並粘貼文件內容，便可建立一個新的粘貼。

每個新的粘貼稱爲一個Gist，並擁有一個單獨的URL。

當一個粘貼建立完畢後，會顯示新創建的Gist頁面, 點擊其中的embed（嵌入）按鈕，就會顯示一段用於嵌入其餘網頁的JavaScript代碼，將上面的JavaScript代碼嵌入到網頁中，便可在相應的網頁中嵌入來自Gist的數據，並保持語法高亮等功能。

經過 web 界面建立文件 🍋

在有些時候，咱們可能不太想用本地建立文件，而後經過git推送到遠程這種方式去建立文件，那麼有沒有簡單高效的一種作法呢？

很簡單，經過github提供的 web 界面建立方式（create new file）去建立就能夠了：

文件查找 🛵

有時，咱們想在一個龐大的 git 倉庫中去查找某一個文件，若是一個一個的去看，可能須要一段時間（我以前時常感受在github倉庫中去查找一個文件真的好麻煩）。

其實 github 提供了一個快捷的查找方式：按鍵盤'T'鍵激活文件查找器，按 ⬆️ 和 ⬇️ 上下選擇文件，固然也能夠輸入你要查找的文件名，快速查找。

github cli(命令行) 🖥

當咱們將本地代碼提交到 GitHub 後，就能夠在 GitHub 網站上查看到各類的交互信息了，例如其它開發者提的 Issue，或者提交的代碼合併請求等。可是，若是咱們能在命令行上直接查看、處理這些信息，那麼這必定很是酷。

下面讓我帶你從 0 到 1 上手GitHub CLI吧！

安裝

要安裝 GitHub CLI 很是簡單。

在macOS下面可使用Homebrew工具進行安裝：

$ brew install github/gh/gh
# 若是須要更新執行下面的命令便可
$ brew update && brew upgrade gh

在Windows下可使用以下命令行進行安裝：

scoop bucket add github-gh https://github.com/cli/scoop-gh.git
scoop install gh

安裝完成後直接在命令行中執行gh命令，看到以下圖所示的信息就說明已經安裝成功了：

其餘平臺的安裝參考官方文檔便可: https://cli.github.com/manual/installation

使用

使用的時候須要咱們進行一次受權：

在命令行中輸入回車鍵就會在瀏覽器中打開受權頁面，點擊受權便可：

受權成功回到命令行，咱們發現經過gh issue list指令已經拿到了issue列表：

我這邊列舉幾個經常使用的操做。

建立 issue

咱們經過 CLI 先交互式地提交了一條issue，issue的 Body 須要經過nano編輯。

篩選 issue

issue列表每每存在有太多的條目，經過指定條件篩選issue是一個很常見的需求：

如上圖所示，它將篩選出label是動態規劃的全部issue

快速瀏覽

找到一個你關注的issue事後，要想查看該issue的具體信息，可使用以下命令在瀏覽器中快速將issue的詳細信息頁面打開：

接下來能夠選擇打開網頁，預覽並提交。固然，咱們也能夠選擇直接在命令行進行提交。

這裏我只是簡單介紹了issue相關的幾個經常使用命令，更多的使用方式能夠查看官方文檔瞭解更多：https://cli.github.com/manual/examples。

GitHub Actions 🚀

GitHub Actions 是 GitHub 的持續集成服務。

一般持續集成是由不少操做組成的，好比抓取代碼、執行腳本、登陸遠程服務器、發佈到第三方服務等。GitHub將這些操做稱做actions。

若是你須要某個 action，沒必要本身寫複雜的腳本，直接引用他人寫好的 action 便可，整個持續集成過程，就變成了一個 actions 的組合。

GitHub 作了一個官方市場，能夠搜索到他人提交的 actions：

下面分別從基本概念和發佈流程詳細說明一下GitHub Actions。

基本概念

• workflow （流程）：持續集成一次運行的過程，就是一個 workflow。
• job （任務）：一個 workflow 由一個或多個 jobs 構成，含義是一次持續集成的運行，能夠完成多個任務。
• step（步驟）：每一個 job 由多個 step 構成，一步步完成。
• action （動做）：每一個 step 能夠依次執行一個或多個命令（action）。

實例：React 項目發佈到 GitHub Pages

這裏經過 GitHub Actions 構建一個 React 項目，併發布到 GitHub Pages。最終代碼都在這個倉庫裏面，發佈後的網址爲https://jack-cool.github.io/github-actions-demo/。

生成密鑰

因爲示例須要將構建成果發到GitHub倉庫，所以須要 GitHub 密鑰。按照官方文檔，生成一個密鑰。而後，將這個密鑰儲存到當前倉庫的Settings/Secrets裏面。

我這裏環境變量的名字用的是ACCESS_TOKEN。

建立 React 項目

使用create-react-app初始化一個 React 應用：

$ npx create-react-app github-actions-demo
$ cd github-actions-demo

在項目的package.json中，添加一個homepage字段（表示該應用發佈後的根目錄）

"homepage": "https://jack-cool.github.io/github-actions-demo"

建立 workflow 文件

在項目的.github/workflows目錄，建立一個workflow文件，這裏用的是ci.yml。

上面已經提到GitHub有一個官方的市場，這裏咱們直接採用的是JamesIves/github-pages-deploy-action：

name: GitHub Actions Build and Deploy Demo
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      # 拉取代碼
      - name: Checkout
        uses: actions/checkout@v2 # If you're using actions/checkout@v2 you must set persist-credentials to false in most cases for the deployment to work correctly.
        with:
          persist-credentials: false
      # 安裝依賴、打包
      - name: Install and Build
        run: |
          npm install
          npm run-script build

      # 部署到 GitHub Pages
      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@releases/v3
        with:
          ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
          BRANCH: gh-pages
          FOLDER: build

這裏梳理下配置文件都作了些什麼：

一、 拉取代碼。這裏用的是 GitHub 官方的 action: actions/checkout@v2

二、安裝依賴、打包

三、部署到GitHub Pages。使用了第三方做者的 action：JamesIves/github-pages-deploy-action@releases/v3。我這裏詳細介紹下這個 action：

使用 with 參數向環境中傳入了三個環境變量：

• ACCESS_TOKEN：讀取 GitHub 倉庫 secrets 的 ACCESS_TOKEN 變量，也就是咱們前面設置的
• BRANCH：部署分支 gh-pages（GitHub Pages 讀取的分支）
• FOLDER：須要部署的文件在倉庫中的路徑，也就是咱們使用 npm run build 生成的打包目錄

這裏有一點須要注意：我使用的是 v3 版本，須要使用 with 參數傳入環境變量，且須要自行構建；網上常見的教程使用的是 v2 版本，使用 env 參數傳入環境變量，不須要自行構建，可以使用 BUILD_SCRIPT 環境變量傳入構建腳本。

到這裏，配置工做就完成了。

之後，你每次有代碼 push 到 master 分支時，GitHub 都會開始自動構建。

分享具體代碼 🎯

平時咱們可能有一行很是好的代碼，想分享給其餘同事看，那麼能夠在url後面加上#L 行號，好比：
https://github.com/Cosen95/rest_node_api/blob/master/app/models/users.js#L17，效果以下圖：

若是是想分享某幾行的，能夠在url後面添加如#L 開始行號-L 結束行號，像https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17-L31，效果以下圖：

經過提交的msg自動關閉 issue 🏉

咱們先來看一下關閉issues的關鍵字：

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

關閉同一個倉庫中的 issue

若是是在同一個倉庫中去關閉issue的話，可使用上面列表中的關鍵字並在其後加上issue編號的引用。

例如一個提交信息中含有fixes #26，那麼一旦此次提交被合併到默認分支，倉庫中的 26 號issue就會自動關閉。

若是此次提交不是在默認分支，那麼這個 issue將不會關閉，可是在它下面會有一個提示信息。這個提示信息會提示你某人添加了一個提交提到了這個 issue，若是你將它合併到默認分支就會關閉該 issue。

關閉不一樣倉庫中的 issue

若是想關閉另外一個倉庫中的issue，可使用username/repository/#issue_number這樣的語法。

例如，提交信息中包含closes Jack-cool/fe_interview/issues/113，將會關閉fe_interview中的113號issue。

關閉其餘倉庫 issue的前提是你將代碼 push到了對應的倉庫

查看項目的訪問數據 🎃

在本身的項目下，點擊 Insights，而後再點擊 Traffic，裏面有 Referring sites 和 Popular content 的詳細數據和排名。

其中 Referring sites 表示你們都是從什麼網站來到你的項目的，Popular content 則表示你們常常看你項目的哪些文件。

任務清單 📝

有時候咱們須要標記一些任務清單去記錄咱們接下來要作的事情。

建立任務列表

issues 和 pull requests 裏能夠添加複選框，語法以下（注意空白符）:

- [ ] 步驟一
- [ ] 步驟二
  - [ ] 步驟2.2
  - [ ] 步驟2.3
- [ ] 步驟三

效果以下：

普通的markdown文件中可建立只讀的任務列表，好比在README.md中添加 TODO list:

### 接下來要作的事 🦀
- [x] 數據結構與算法
- [ ] react源碼
- [ ] docker

效果以下：

對任務排序

你能夠單擊任務左邊的複選框並拖放至新位置，對單一評論中的任務列表從新排序。

issues 模版和 pull request 模版 🍪

這裏以 issue模版舉例， pr模板相似

這個issue模版我是在給element ui提issue時發現的：

在GitHub中，代碼庫維護者若是提供有定製的 issues 模版和pull request 模版，可讓人們有針對性的提供某類問題的準確信息，從而在後續維護中可以進行有效地對話和改進，而不是雜亂無章的留言。

建立issues模版

• 在代碼庫根目錄新建.github目錄
• 在 .github 目錄下添加 ISSUE_TEMPLATE.md 文件做爲 issues 默認模版。當建立 issue 時，系統會自動引用該模版。

如我在項目根目錄下新建了.github/ISSUE_TEMPLATE.md：

## 概述

bug 概述

## 重現步驟

1. aaa
2. bbb
3. ccc

## Bug 行爲

Bug 的表現行爲

## 指望行爲

軟件的正確行爲

## 附件

附上圖片或日誌，日誌請用格式：

> ```
> 日誌內容
> ```

在該倉庫新建issue時就會出現上面預設的issue模版：

GitHub Wiki 📜

你們平時的項目，通常都使用 Markdown 來編寫項目文檔和 README.md 等。Markdown 通常狀況下可以知足咱們的文檔編寫需求，若是使用得當的話，效果也很是棒。不過當項目文檔比較長的時候，閱讀體驗可能就不是那麼理想了，這種狀況我想你們應該都曾經遇到過。

GitHub 每個項目都有一個單獨完整的 Wiki 頁面，咱們能夠用它來實現項目信息管理，爲項目提供更加完善的文檔。咱們能夠把 Wiki 做爲項目文檔的一個重要組成部分，將冗長、具體的文檔整理成 Wiki，將精簡的、概述性的內容，放到項目中或是 README.md 裏。

關於Wiki的使用，這裏就不展開說明了，具體能夠參考官方文檔

查看提交記錄熱度圖 👨‍🚀

查看文件時，能夠按b查看提交記錄和顯示每一行的最近修改狀況的熱度圖。它會告訴你每行代碼的提交人，而且提供一個能夠點擊的連接去查看完整提交。

中間有一個橙色的豎條。顏色越鮮豔，更改的時間就越近。

Git Submodules vs Git Subtrees 👨‍🌾

爲何使用 Submodules or Subtrees?

團隊中通常都會有公共的代碼庫，submodule和subtrees可讓咱們在不一樣項目中使用這些公共的代碼，避免因拷貝產生重複代碼，甚至致使相同代碼出現不一樣修改產生多個版本。

區別

subtree 和 submodule 的目的都是用於 git 子倉庫管理，兩者的主要區別在於，subtree 屬於拷貝子倉庫，而 submodule 屬於引用子倉庫。

使用

關於實踐，官方文檔寫的已經很是清楚了，我這裏直接放上連接：

• submodule: https://git-scm.com/book/en/v2/Git-Tools-Submodules
• subtree: https://einverne.github.io/post/2020/04/git-subtree-usage.html

GitHub 插件推薦 🦐

GitHub的插件有不少不少，這裏就推薦一下我經常使用的三個插件。

Octotree

咱們有時常常須要在github上查找文件，但若是文件結構嵌套很深，查找起來是很是麻煩的，這時使用Octotree能夠在倉庫左側顯示當前項目的目錄結構，讓你能夠在github上像使用Web IDE同樣方便。

isometric-contributions

這個是能夠更酷炫的 3D 立體式渲染github貢獻。

Enhanced GitHub

這個插件支持在倉庫中顯示倉庫大小、每一個文件的大小以及每一個文件的下載連接。

GitHub 吉祥物 Octocat 🦊

哈哈 這個就比較有意思了 我也是剛知道原來github也有本身的吉祥物。

這裏貼下網站，順便選了幾個感受很萌的，你們也能夠去上面選幾個做爲本身的頭像什麼的。

參考

• 阮一峯老師 《GitHub Actions 入門教程》

愛心三連擊 ❤

一、若是感受內容對你有幫助，也歡迎你分享給更多的朋友。

二、關注公衆號前端森林，按期爲你推送新鮮乾貨好文。

三、添加微信fs1263215592，拉你進技術交流羣一塊兒學習 🍻