Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the useful Github functions". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the useful Github functions"?

Gist

Many people may not have heard of Gist. It is under the subdirectory of the front page of github:

This is a very useful feature provided by github. Gist is a tool for pasting data, just like Pastie sites, you can easily paste data into Gist sites and reference data pasted in Gist in other pages.

As a subsite of GitHub, Gist naturally uses the Git version library to maintain pasted data, which is very convenient.

Go to the home page of the Gist website and you will see a large data paste dialog box. Simply provide a single line of description, file name, and paste the contents of the file to create a new paste.

Each new paste is called a Gist and has a separate URL.

When a paste is created, it will display the newly created Gist page, click the embed (embed) button, it will show a section of JavaScript code for embedding other web pages, and embed the above JavaScript code into the page, you can embed the data from Gist in the corresponding page, and keep the syntax highlighted and other functions.

Create a file through the web interface

In some cases, we may not want to create files locally and then push them remotely through git, so is there a simple and efficient way to create files?

Very simply, you can create it through the web interface creation method (create new file) provided by github:

File lookup

Sometimes, we want to find a file in a large git repository, and if we look at it one by one, it may take a while (I often felt that it was really troublesome to find a file in the github repository).

In fact, github provides a quick way to find: press the keyboard'T 'key to activate the file finder, press ⬆️ and ⬇️ to select files up and down, of course, you can also enter the file name you want to find, quick search.

Github cli (command line)

When we submit the local code to GitHub, we can view a variety of interactive information on the GitHub website, such as Issue mentioned by other developers, or submitted code merge requests, etc. However, it would be cool if we could view and process this information directly on the command line.

Now let me take you from 0 to 1 to start GitHub CLI!

Installation

It is very easy to install GitHub CLI.

You can use the Homebrew tool to install under macOS:

$brew install github/gh/gh # if you need to update and execute the following command, you can $brew update & & brew upgrade gh

You can install it under Windows using the following command line:

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

After the installation is completed, execute the gh command directly on the command line. The information shown in the following figure indicates that the installation has been successful:

For installation of other platforms, please refer to the official documentation: https://cli.github.com/manual/installation

Use

We need to make an authorization when using it:

Enter the enter key on the command line to open the authorization page in the browser. Click Authorization:

Authorization successfully returns to the command line, and we find that we have obtained the issue list through the gh issue list instruction:

Let me list a few common operations here.

Create issue

We first interactively submit an issue,issue Body through CLI that needs to be edited through nano.

Filter issue

There are often too many entries in issue lists, and it is a common requirement to filter issue by specifying criteria:

As shown in the figure above, it will filter out all issue whose label is dynamic planning

Quick browsing

After finding an issue you follow, to view the specific information of the issue, you can quickly open the details page of the issue in the browser using the following command:

Next, you can choose to open the web page, preview and submit. Of course, we can also choose to submit directly on the command line.

Here I just briefly introduce a few common commands related to issue. For more ways to use them, you can check the official documentation to learn more: https://cli.github.com/manual/examples.

GitHub Actions

GitHub Actions is a continuous integration service for GitHub.

Usually continuous integration consists of many operations, such as grabbing substitution code, executing scripts, logging in to remote servers, publishing to third-party services, and so on. GitHub calls these operations actions.

If you need an action, you don't have to write a complex script yourself, just refer to the action written by others, and the whole continuous integration process becomes a combination of actions.

GitHub has created an official market to search for actions submitted by others:

The following is a detailed description of GitHub Actions from the basic concepts and the release process.

Basic concept

Workflow (process): a running process of continuous integration is a workflow.

Job (tasks): a workflow consists of one or more jobs, meaning a continuous integration run that can accomplish multiple tasks.

Step (step): each job is composed of multiple step, which is completed step by step.

Action (action): each step can execute one or more commands in turn (action).

Example: React project published to GitHub Pages

Here you build a React project through GitHub Actions and publish it to GitHub Pages. The final code is in this warehouse, and the released URL is https://jack-cool.github.io/github-actions-demo/.

Generate key

Because the example needs to send the build results to the GitHub repository, the GitHub key is required. Generate a key according to the official documentation. The key is then stored in the Settings/Secrets of the current warehouse.

The name of the environment variable here is ACCESS_TOKEN.

Create a React project

Initialize a React application using create-react-app:

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

In the package.json of the project, add a homepage field (representing the root directory after the application is published)

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

Create a workflow file

In the project's .GitHub / workflows directory, create a workflow file, using ci.yml.

It has been mentioned above that there is an official market for GitHub, here we directly use 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: # pull substitution code-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 # installation dependency, Package-name: Install and Build run: | npm install npm run-script build # deploy to GitHub Pages-name: Deploy uses: JamesIves/github-pages-deploy-action@releases/v3 with: ACCESS_TOKEN: ${{secrets.ACCESS_TOKEN}} BRANCH: gh-pages FOLDER: build

Here's a look at what the configuration file does:

1. Pull the code. GitHub's official action: actions/checkout@v2 is used here.

2. Installation dependency and packaging

3. Deploy to GitHub Pages. The action:JamesIves/github-pages-deploy-action@releases/v3 of the third-party author is used. Let me introduce this action in detail here:

Three environment variables are passed into the environment using the with parameter:

ACCESS_TOKEN: read the ACCESS_TOKEN variable of the GitHub repository secrets, which is the one we set earlier

BRANCH: deploy branch gh-pages (branch read by GitHub Pages)

FOLDER: the path of the files that need to be deployed in the repository, that is, the packaging directory that we generated using npm run build

There is one thing to note here: I use v3 version, which needs to use the with parameter to pass in environment variables, and need to build it myself; the common tutorials on the Internet use v2 version, which uses env parameter to pass in environment variables, so you don't need to build them yourself. You can use BUILD_SCRIPT environment variables to pass in the build script.

At this point, the configuration is complete.

In the future, every time you have a code push to master branch, GitHub will start to build automatically.

Share specific code

Usually we may have a very good line of code that we want to share with other colleagues, so we can add a # L line number after url, such as https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17, as shown below:

If you want to share certain lines, you can add a line number such as # L starting line number-L ending line number after url, such as https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17-L31, as shown below:

Automatically close the issue through the submitted msg

Let's first take a look at the keyword that closes issues:

Close

Closes

Closed

Fix

Fixes

Fixed

Resolve

Resolves

Resolved

Shut down issue in the same warehouse

If you are shutting down issue in the same warehouse, you can use the keywords in the list above and follow them with a reference to the issue number.

For example, if a submission message contains fixes # 26, once the commit is merged into the default branch, issue No. 26 in the warehouse will be automatically closed.

If this submission is not in the default branch, the issue will not be closed, but there will be a message below it. This prompt will prompt you that someone has added a submission that mentions the issue, and if you merge it into the default branch, the issue will be closed.

Close issue in different warehouses

If you want to shut down issue in another repository, you can use syntax like username/repository/#issue_number.

For example, if closes Jack-cool/fe_interview/issues/113 is included in the submission message, issue number 113in fe_interview will be closed.

The premise of shutting down other warehouse issue is that you push the code to the corresponding warehouse.

View the access data for the project

Under your own project, click Insights, and then click Traffic, which contains detailed data and rankings of Referring sites and Popular content.

Referring sites says what website everyone came to your project from, and Popular content says which files people often look at about your project.

Task list

Sometimes we need to mark a to-do list to record what we need to do next.

Create a task list

Check boxes can be added to issues and pull requests. The syntax is as follows (note the blank character):

-[] step 1-[] step 2-[] step 2.2-[] step 2.3-[] step 3

The effect is as follows:

You can create a read-only task list in a normal markdown file, such as adding TODO list to README.md:

# what to do next?-[x] data structure and algorithm-[] react source code-[] docker

The effect is as follows:

Sort tasks

You can reorder the task list in a single comment by clicking the check box on the left of the task and dragging and dropping it to a new location.

Issues template and pull request template

Here is an example of the issue template, which is similar to the pr template.

I found this issue template when I was mentioning issue to element ui:

In GitHub, code base maintainers who provide customized issues templates and pull request templates can enable people to provide accurate information about certain types of problems, so that they can effectively talk and improve in the follow-up maintenance, rather than messy messages.

Create an issues template

Create a new .github directory in the root directory of the code base

Add the ISSUE_TEMPLATE.md file as the issues default template in the .GitHub directory. When you create an issue, the template is automatically referenced.

For example, I created a new .GitHub / ISSUE_TEMPLATE.md under the root of the project:

# # Overview of bug # # reproduce step 1. Aaa 2. Bbb 3. Ccc # # performance behavior of Bug behavior # # correct behavior of expected behavior software # # attached with a picture or log, log format: > ```> log content >```

When you create a new issue in the repository, the issue template preset above will appear:

GitHub Wiki

We usually use Markdown to write project documents and README.md for our usual projects. Markdown generally meets our documentation needs, and if used properly, the effect is great. However, when the project document is long, the reading experience may not be so ideal, which I think we have all encountered before.

GitHub each project has a separate and complete Wiki page, which we can use to manage project information and provide more complete documentation for the project. We can take Wiki as an important part of project documents, organize lengthy, specific documents into Wiki, and put concise, summary content into the project or README.md.

With regard to the use of Wiki, we will not explain it here. You can refer to the official documentation for details.

View the heat map of the submission record

When viewing the file, you can press b to view the submission record and a heat map showing the most recent changes to each line. It will tell you the author of each line of code and provide a clickable link to view the full submission.

There is an orange vertical bar in the middle. The brighter the color, the closer it will be to change.

Git Submodules vs Git Subtrees

Why use Submodules or Subtrees?

There is usually a common code base in the team, and submodule and subtrees allow us to use this common code in different projects to avoid duplicating code due to copying, or even lead to different changes to the same code resulting in multiple versions.

Difference

Both subtree and submodule are used for git sub-warehouse management. The main difference between them is that subtree belongs to copy sub-warehouse and submodule belongs to reference sub-warehouse.

Use

With regard to practice, the official document is very clear, and I will put the link directly here:

Submodule: https://git-scm.com/book/en/v2/Git-Tools-Submodules

Subtree: https://einverne.github.io/post/2020/04/git-subtree-usage.html

GitHub plug-in recommendation

There are many plug-ins for GitHub, so here are three plug-ins that I often use.

Octotree

We sometimes need to find files on github, but if the file structure is deeply nested, it is very troublesome to find it, then using Octotree can display the directory structure of the current project on the left side of the warehouse, so that you can use github as convenient as using Web IDE.

Isometric-contributions

This is a cooler 3D rendering github contribution.

Enhanced GitHub

This plug-in supports displaying the warehouse size, the size of each file, and the download link for each file in the repository.

GitHub mascot Octocat

Haha, this is more interesting. I just learned that github also has its own mascot.

Post the website here, by the way, choose some that feel very cute, and you can also go there and choose some of them as your avatars and so on.

Thank you for your reading, the above is the content of "what are the useful Github functions". After the study of this article, I believe you have a deeper understanding of what useful Github functions there are, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.