关于github:你可能不知道的15个有用的Github功能

2次阅读

共计 6612 个字符，预计需要花费 17 分钟才能阅读完成。

咱们平时的工作中，github是必不可少的代码托管平台，然而大多数同学也只是把它做为了托管代码的中央，并没有正当的去使用。

其实 github 外面有十分多好玩或者乏味的中央的。当然，这些技巧也能对你的工作效率有很大的晋升。

我整顿了一些本人平时用的比拟多的一些性能 / 技巧，也心愿能给你的工作带来一些帮忙！

可能很多人并没有听过 Gist。它在github 首页的子目录下：

这是 github 提供的一个十分有用的性能。Gist作为一个粘贴数据的工具，就像 Pastie 网站一样，能够很容易地将数据粘贴在 Gist 网站中，并在其余网页中援用 Gist 中粘贴的数据。

作为 GitHub 的一个子网站，很天然地，Gist应用 Git 版本库对粘贴数据进行保护，这是十分不便的。

进入 Gist 网站的首页，就会看到一个大大的数据粘贴对话框. 只有提供一行简略的形容、文件名，并粘贴文件内容，即可创立一个新的粘贴。

每一个新的粘贴称为一个Gist，并领有一个独自的URL。

当一个粘贴创立结束后，会显示新建设的 Gist 页面, 点击其中的 embed（嵌入）按钮，就会显示一段用于嵌入其余网页的JavaScript 代码，将下面的 JavaScript 代码嵌入到网页中，即可在相应的网页中嵌入来自 Gist 的数据，并放弃语法高亮等性能。

在有些时候，咱们可能不太想用本地创立文件，而后通过 git 推送到近程这种形式去创立文件，那么有没有简略高效的一种做法呢？

很简略，通过 github 提供的 web 界面创立形式（create new file）去创立就能够了：

有时，咱们想在一个宏大的 git 仓库中去查找某一个文件，如果一个一个的去看，可能须要一段时间（我之前时常感觉在 github 仓库中去查找一个文件真的好麻烦）。

其实 github 提供了一个快捷的查找形式：按键盘 ’T’ 键激活文件查找器，按 ⬆️ 和 ⬇️ 高低抉择文件，当然也能够输出你要查找的文件名，疾速查找。

当咱们将本地代码提交到 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 列表：

我这边列举几个罕用的操作。

咱们通过 CLI 先交互式地提交了一条 issue，issue 的 Body 须要通过 nano 编辑。

issue列表往往存在有太多的条目，通过指定条件筛选 issue 是一个很常见的需要：

如上图所示，它将筛选出 label 是动静布局 的所有issue

找到一个你关注的 issue 过后，要想查看该 issue 的具体信息，能够应用如下命令在浏览器中疾速将 issue 的详细信息页面关上：

接下来能够抉择关上网页，预览并提交。当然，咱们也能够抉择间接在命令行进行提交。

这里我只是简略介绍了 issue 相干的几个常用命令，更多的应用形式能够查看官网文档理解更多：https://cli.github.com/manual/examples。

GitHub Actions 是 GitHub 的继续集成服务。

通常 继续集成 是由很多操作组成的，比方抓取代码、执行脚本、登录近程服务器、公布到第三方服务等。GitHub将这些操作称作actions。

如果你须要某个 action，不用本人写简单的脚本，间接援用别人写好的 action 即可，整个继续集成过程，就变成了一个 actions 的组合。

GitHub 做了一个官网市场，能够搜寻到别人提交的 actions：

上面别离从基本概念和公布流程具体阐明一下GitHub Actions。

workflow（流程）：继续集成一次运行的过程，就是一个 workflow。
job（工作）：一个 workflow 由一个或多个 jobs 形成，含意是一次继续集成的运行，能够实现多个工作。
step（步骤）：每个 job 由多个 step 形成，一步步实现。
action（动作）：每个 step 能够顺次执行一个或多个命令（action）。

这里通过 GitHub Actions 构建一个 React 我的项目，并公布到 GitHub Pages。最终代码都在这个仓库外面，公布后的网址为https://jack-cool.github.io/github-actions-demo/。

因为示例须要将构建成绩发到 GitHub 仓库，因而须要 GitHub 密钥。依照官网文档，生成一个密钥。而后，将这个密钥贮存到以后仓库的 Settings/Secrets 外面。

我这里环境变量的名字用的是ACCESS_TOKEN。

应用 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"

在我的项目的 .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

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

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 编号的援用。

例如一个提交信息中含有 fixes #26，那么一旦这次提交被合并到默认分支，仓库中的 26 号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 模版：

大家平时的我的项目，个别都应用 Markdown 来编写我的项目文档和 README.md 等。Markdown 个别状况下可能满足咱们的文档编写需要，如果应用切当的话，成果也十分棒。不过当我的项目文档比拟长的时候，浏览体验可能就不是那么现实了，这种状况我想大家应该都已经遇到过。

GitHub 每一个我的项目都有一个独自残缺的 Wiki 页面，咱们能够用它来实现我的项目信息管理，为我的项目提供更加欠缺的文档。咱们能够把 Wiki 作为我的项目文档的一个重要组成部分，将简短、具体的文档整顿成 Wiki，将精简的、概述性的内容，放到我的项目中或是 README.md 里。

对于 Wiki 的应用，这里就不开展阐明了，具体能够参考官网文档

查看文件时，能够按 b 查看提交记录和显示每一行的最近批改状况的热度图。它会通知你每行代码的提交人，并且提供一个能够点击的链接去查看残缺提交。

两头有一个橙色的竖条。色彩越娇艳，更改的工夫就越近。

团队中个别都会有公共的代码库，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 上像应用 Web IDE 一样不便。

这个是能够更酷炫的 3D 立体式渲染 github 奉献。

这个插件反对在仓库中显示仓库大小、每个文件的大小以及每个文件的下载链接。

GitHub 吉祥物 `Octocat` ????

哈哈这个就比拟有意思了我也是刚晓得原来 github 也有本人的吉祥物。

这里贴下网站，顺便选了几个感觉很萌的，大家也能够去下面选几个作为本人的头像什么的。

阮一峰老师《GitHub Actions 入门教程》

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

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

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

正文完

github

发表至： github

2020-11-02

0

关于github:Scalpel解构API复杂参数Fuzz的手术刀

GitHub\-JavaScript-趋势榜项目第29周

关于github:我在-GitHub-上发现了一款骚气满满的字体

关于github:维格小程序已在-Github-开源雷达图热力图趋势图…更多全新图表等你来领

关于echarts:echarts绘制彩虹图去掉底部白色线条

关于github:你可能不知道的15个有用的Github功能

引言 ????

Gist ????

通过 web 界面创立文件 ????

文件查找 ????

github cli(命令行) ????

装置

应用

创立 issue

筛选 issue

疾速浏览

GitHub Actions ????

基本概念

实例：React 我的项目公布到 GitHub Pages

生成密钥

创立 React 我的项目

创立 workflow 文件

分享具体代码 ????

通过提交的 msg 主动敞开 issue ????

敞开同一个仓库中的 issue

敞开不同仓库中的 issue

查看我的项目的拜访数据 ????

工作清单 ????

创立工作列表

对工作排序

issues 模版和 pull request 模版 ????

创立 issues 模版

GitHub Wiki ????

查看提交记录热度图 ????‍????

Git Submodules vs Git Subtrees ????‍????

为什么应用 Submodules or Subtrees?

区别

应用

GitHub 插件举荐 ????

Octotree

isometric-contributions

Enhanced GitHub

GitHub 吉祥物 Octocat ????

参考

爱心三连击 ❤

站内搜索

通过提交的 `msg` 主动敞开 issue ????

`issues` 模版和 `pull request` 模版 ????

创立 `issues` 模版

GitHub 吉祥物 `Octocat` ????