引言 ????

咱们平时的工作中，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.gitscoop 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 Demoon:  push:    branches:      - masterjobs:  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

这里梳理下配置文件都做了些什么：

1、 拉取代码。这里用的是 GitHub 官网的 action: actions/checkout@v2

2、装置依赖、打包

3、部署到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. aaa2. bbb3. 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 入门教程》

爱心三连击 ❤

1、如果感觉内容对你有帮忙，也欢送你分享给更多的敌人。

2、关注公众号前端森林，定期为你推送陈腐干货好文。

3、增加微信fs1263215592，拉你进技术交换群一起学习 ????