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

时间  2020-11-10
标签 html 前端 node react git github web 算法 docker npm 栏目 Git 繁體版
原文   原文链接

image

引言 🏂

咱们平时的工做中，github是必不可少的代码托管平台，可是大多数同窗也只是把它作为了托管代码的地方，并无合理的去运用。html

其实github里面有很是多好玩或者有趣的地方的。固然，这些技巧也能对你的工做效率有很大的提高。前端

我整理了一些本身平时用的比较多的一些功能/技巧，也但愿能给你的工做带来一些帮助！node

Gist 🍓

可能不少人并无听过Gist。它在github首页的子目录下：
imagereact

这是github提供的一个很是有用的功能。Gist做为一个粘贴数据的工具，就像 Pastie 网站同样，能够很容易地将数据粘贴在Gist网站中，并在其余网页中引用Gist中粘贴的数据。git

做为GitHub的一个子网站，很天然地，Gist使用Git版本库对粘贴数据进行维护，这是很是方便的。github

进入Gist网站的首页，就会看到一个大大的数据粘贴对话框. 只要提供一行简单的描述、文件名，并粘贴文件内容，便可建立一个新的粘贴。web

每个新的粘贴称为一个Gist，并拥有一个单独的URL。算法

当一个粘贴建立完毕后，会显示新创建的Gist页面, 点击其中的embed（嵌入）按钮，就会显示一段用于嵌入其余网页的JavaScript代码，将上面的JavaScript代码嵌入到网页中，便可在相应的网页中嵌入来自Gist的数据，并保持语法高亮等功能。
imagedocker

经过 web 界面建立文件 🍋

在有些时候，咱们可能不太想用本地建立文件，而后经过git推送到远程这种方式去建立文件，那么有没有简单高效的一种作法呢？npm

很简单，经过github提供的 web 界面建立方式（create new file）去建立就能够了：

文件查找 🛵

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

其实 github 提供了一个快捷的查找方式：按键盘'T'键激活文件查找器，按 ⬆️ 和 ⬇️ 上下选择文件，固然也能够输入你要查找的文件名，快速查找。

github cli(命令行) 🖥

image

当咱们将本地代码提交到 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命令，看到以下图所示的信息就说明已经安装成功了：
image
其余平台的安装参考官方文档便可: https://cli.github.com/manual/installation

使用

使用的时候须要咱们进行一次受权：
image

在命令行中输入回车键就会在浏览器中打开受权页面，点击受权便可：
image
受权成功回到命令行，咱们发现经过gh issue list指令已经拿到了issue列表：
image

我这边列举几个经常使用的操做。

建立 issue

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

筛选 issue

issue列表每每存在有太多的条目，经过指定条件筛选issue是一个很常见的需求：
image
如上图所示，它将筛选出label是动态规划的全部issue

快速浏览

找到一个你关注的issue事后，要想查看该issue的具体信息，可使用以下命令在浏览器中快速将issue的详细信息页面打开：
image
接下来能够选择打开网页，预览并提交。固然，咱们也能够选择直接在命令行进行提交。

这里我只是简单介绍了issue相关的几个经常使用命令，更多的使用方式能够查看官方文档了解更多：https://cli.github.com/manual/examples。

GitHub Actions 🚀

image
GitHub Actions 是 GitHub 的持续集成服务。

一般持续集成是由不少操做组成的，好比抓取代码、执行脚本、登陆远程服务器、发布到第三方服务等。GitHub将这些操做称做actions。

若是你须要某个 action，没必要本身写复杂的脚本，直接引用他人写好的 action 便可，整个持续集成过程，就变成了一个 actions 的组合。

GitHub 作了一个官方市场，能够搜索到他人提交的 actions：
image
下面分别从基本概念和发布流程详细说明一下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里面。
image
我这里环境变量的名字用的是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，效果以下图：
image

若是是想分享某几行的，能够在url后面添加如#L 开始行号-L 结束行号，像https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17-L31，效果以下图：
image

经过提交的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
- [ ] 步骤三

效果以下：
image

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

### 接下来要作的事 🦀
- [x] 数据结构与算法
- [ ] react源码
- [ ] docker

效果以下：
image

对任务排序

你能够单击任务左边的复选框并拖放至新位置，对单一评论中的任务列表从新排序。
image

issues 模版和 pull request 模版 🍪

这里以 issue模版举例， pr模板相似

这个issue模版我是在给element ui提issue时发现的：
image

在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 📜

image

你们平时的项目，通常都使用 Markdown 来编写项目文档和 README.md 等。Markdown 通常状况下可以知足咱们的文档编写需求，若是使用得当的话，效果也很是棒。不过当项目文档比较长的时候，阅读体验可能就不是那么理想了，这种状况我想你们应该都曾经遇到过。

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

关于Wiki的使用，这里就不展开说明了，具体能够参考官方文档

查看提交记录热度图 👨‍🚀

查看文件时，能够按b查看提交记录和显示每一行的最近修改状况的热度图。它会告诉你每行代码的提交人，而且提供一个能够点击的连接去查看完整提交。

中间有一个橙色的竖条。颜色越鲜艳，更改的时间就越近。

Git Submodules vs Git Subtrees 👨‍🌾

image

为何使用 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

image

咱们有时常常须要在github上查找文件，但若是文件结构嵌套很深，查找起来是很是麻烦的，这时使用Octotree能够在仓库左侧显示当前项目的目录结构，让你能够在github上像使用Web IDE同样方便。
image

isometric-contributions

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

Enhanced GitHub

image
这个插件支持在仓库中显示仓库大小、每一个文件的大小以及每一个文件的下载连接。
image

GitHub 吉祥物 Octocat 🦊

哈哈 这个就比较有意思了 我也是刚知道原来github也有本身的吉祥物。

这里贴下网站，顺便选了几个感受很萌的，你们也能够去上面选几个做为本身的头像什么的。
image

image

image

参考

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

爱心三连击 ❤

一、若是感受内容对你有帮助，也欢迎你分享给更多的朋友。

二、关注公众号前端森林，按期为你推送新鲜干货好文。

三、添加微信fs1263215592，拉你进技术交流群一块儿学习 🍻
image

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程