Basic use of git (configuration file, log / reference log, version fallback, undo elimination, modify commit submission)

0 background

This article is summarized in the git tutorial of gitcode.

1 History

In order to manage the code merging of the Linux system, Linus Torvalds used the distributed version control system BitKeeper at the beginning. Since the permission is withdrawn later, Linus firmly opposes CVS and SVN (although it is free, it is not only slow, but also must be connected to the Internet, and others need to be paid), So Linus used C to develop the distributed management system git in two weeks.

In 2008, GitHub website was launched. It provides git storage for open source projects for free. Countless open source projects began to migrate to GitHub, including jQuery, PHP, Ruby and so on. Let git grow.

2. Use of GIT configuration file

Custom configuration files are usually stored in the warehouse git/config file, and the GIT configuration file of the current user is placed in a hidden file in the user's home directory In gitconfig.

Example of global configuration file:

$ cat .git/config 
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url =
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
    last = log -1

⚠️ Note: the alias is right after [alias]. To delete the alias, delete the corresponding line directly.

User profile:

$ cat .gitconfig
    co = checkout
    ci = commit
    br = branch
    st = status
    name = Your Name
    email =
	ui = true

2.1 setting user name and email address

$ git config --global "Miss Li"
$ git config --global

2.2 view configuration

$ git config --list "Miss Li"

You may see duplicate variable names because Git reads the same configuration from different files (for example: / etc/gitconfig and ~ /. Gitconfig)

You can also check a Git configuration by entering Git config < key >:,

$ git config
 Miss Li

2.3 modify the configuration to ignore files (i.e. do not upload files) and force the upload of ignored files

The core point is modification gitignore file.

Here is an example Example of gitignore file:

# Windows:

# Python:

# My configurations:

# Exclude all Hidden files at the beginning:
# Exclude all class file:

# Not excluded gitignore and app class:

be careful ⚠️: Exclude specified files from The way to write outside the gitignore rule is+ File name.

The. gitignore file generally does not need to be written manually. Common configuration file information( link)

Check ignore rule:

$ git check-ignore -v App.class
.gitignore:3:*.class	App.class

Force upload of ignored files:

$ git add -f App.class

2.4 configuring aliases

For example, in the following example, st means status, cm means commit, etc. (-- global parameter is a global parameter, that is, these commands can be used in all Git warehouses on this computer.)

$ git config --global status

$ git config --global checkout
$ git config --global commit
$ git config --global branch

Once configured, you can use ci instead of commit.

$ git ci -m "sth."

Other common alias configurations:

$ git config --global alias.unstage 'reset HEAD'

# $ git unstage  
## The actual execution is: $git reset head test py

3. Use git

3.1 create a version Library in the existing directory

# 1. Create file directory
$ mkdir learning-git
$ cd learning-git
$ pwd

# 2. Initialize warehouse
$ git init
Initialized empty Git repository in /Users/xxm/learning-git/.git/

# 3. Clone the existing warehouse 
# This will create a directory named help docs in the current directory and initialize a directory in this directory git folder, pull down all data from the remote warehouse and put it in git folder, and then read a copy of the latest version of the file from it. 
#  git clone <url> 
$ git clone
# Customize the name of the local warehouse and specify a new directory name through additional parameters (the following column is to replace help docs with mydocs)
# $ git clone mydocs

3.2 uploading git

The following picture is from Liao Xuefeng's official website:

# 1. Upload files
$ git add readme.txt

# 2. Add description
$ git commit -m "wrote a readme file"
[master (root-commit) 50ed06b] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

# 3. View the results submitted to the cache
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

# See what has been modified
$ git diff readme.txt 

4,Add branch to remote warehouse
$ git push
# The first version submission uses the following method
# It will not only push the contents of the local master branch to the new remote master branch, but also associate the local master branch with the remote master branch
# $ git push -u origin master

git push -u explain:
It mainly means branch< name>. Merge and branch< name>. Remote defines the upstream of a given branch. It tells git fetch/git pull which branch to merge, and can also affect git push
Upstream is the primary repository that others will get from, such as your GitHub repository- The u option automatically sets the upstream for you, linking your warehouse to a central warehouse. In this way, GIT will "know" where you want to push and where you want to extract information in the future, so you can use git pull or git push without parameters. When you git pull from a branch without specifying the source or remote branch, GIT will view the branch< name>. Merge settings to see where to extract. It is the git push -u command that sets this information for the branch you want to push.
So far, simply put, taking the - u parameter is actually equivalent to recording the default value of pushing to the remote branch, so that the push command can be abbreviated as git push when we want to continue pushing the remote branch next time.

3.3 modify commit submission

3.3.1 merge several commit submissions

Sometimes after submitting, we find that several files are missing and not added, or the submitted information is written incorrectly. At this point, you can run the submit command with the -- amend option to resubmit:

👉 git commit --amend

$ git commit --amend

This command will commit the files in the staging area. If you have not made any changes since the last submission (for example, you executed this command immediately after the last submission), the snapshot will remain unchanged, and all you have modified is the submission information.

For example, after submitting, you find that you forgot to temporarily save some required modifications. You can do the following:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

Eventually you will only have one submission - the second submission will replace the results of the first submission.

It's important to understand that when you fix the final submission, you don't fix it by replacing the old submission in situ with the improved submission. In effect, as if the old submission had never existed, it would not appear in the history of the warehouse.
The most obvious value of patching submission is that it can slightly improve your final submission without confusing your warehouse history with submission information such as "ah, forgot to add a file" or "minor patching, correcting clerical errors".

3.3.2 separate commit submission

You can use git reset head < File > To cancel staging to cancel staging readme Txt file:

$ git reset HEAD readme.txt
Unstaged changes after reset:
M	readme.txt

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    LICENSE ->

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

readme.txt file has been modified but not temporarily stored.

git reset is indeed a dangerous command, especially if the -- hard option is added. However, in the above scenario, the files in the working directory have not been modified, so it is relatively safe.

3.3.3 undo previous changes

Use the GIT checkout -- > File > instruction:

$ git checkout -- readme.txt
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    LICENSE ->

You can see that those changes have been undone.

Remember that Git checkout -- < File > is a dangerous command. Any local changes you make to that file will disappear - Git will overwrite it with the most recently submitted version. Do not use this command unless you know that you do not want to make local changes to that file.

3.4 delete

3.4.1 it is really necessary to delete a file

$ rm test.txt

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test.txt"
[master 5c7e5ea] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

3.4.2 a file was deleted by mistake

$ rm test.txt

# Restore the wrongly deleted file to the latest version from the version library
$ git checkout -- test.txt

4 log

4.1 view recently submitted logs

$ git log
commit e55063ad7f97dd979e4f94e12d2bc44a25a0fd55 (HEAD -> master)
Author: Miykael_xxm <>
Date:   Fri Nov 27 16:08:04 2020 +0800

    add distributed

commit 50ed06bd62fd34afbe501e6f2a4af73ccbe187f0
Author: Miykael_xxm <>
Date:   Fri Nov 27 16:06:11 2020 +0800

    wrote a readme file

The git log command displays the latest and farthest submission logs. We can see two submissions, the latest one is add distributed, and the earliest one is write a readme file.

4.2 display log in Timeline mode

Automatically string git submissions into a timeline:

--pretty=oneline: displayed in one line, only the hash value and submission description are displayed

$ git log --pretty=oneline
e55063ad7f97dd979e4f94e12d2bc44a25a0fd55 (HEAD -> master) add distributed
50ed06bd62fd34afbe501e6f2a4af73ccbe187f0 wrote a readme file

More intuitive display:

--graph: displays the branch merge history represented by ASCII graphics
--Abrev commit: only the first few characters of SHA-1 are displayed
- pretty =: use other formats to display historical submission information. The options are: oneline,short,medium,full,fuller,email,raw and format: < string >, and the default is medium.

$ git log --graph --pretty=oneline --abbrev-commit

*   082cad1 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'master' of
| *   d56e63b Merge branch 'feature1' into 'master'
| |\
| | *   31b4c13 (origin/feature1) Creating a new branch is quick and simple.
| | |\
| | |/
| |/|
| | * 13dcd3e (feature1) ADD A SAMPLE
* | | 0113c18 Modification conflict
|/ /
* | 7f34e0e & simple
* | 9024f59 ADD A SAMPLE
* f2f9a97 Update
* 5d7e8d4 Initial commit

4.3 display reference log

git reflog

git relog interpretation:
Reflog is not a part of GIT warehouse. It is stored separately. It is purely local. (the contents displayed by the git reflog command should be stored in the. git/logs/HEAD file or in the. git/logs/refs directory.)
In other words, the git reflog command retains all the operations of the user in the local library starting from the clone warehouse.

5 version fallback

Principle: Git internally has a HEAD pointer to the current version. When you fallback the version, Git only points the HEAD from the to the fallback version.

5.1 fallback to previous version

$ git reset --hard HEAD^
HEAD is now at 50ed06b wrote a readme file

5.2 fallback to version number

git reset --hard commit-id


$ git reflog
50ed06b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~
e55063a HEAD@{1}: reset: moving to HEAD
e55063a HEAD@{2}: commit: add distributed
50ed06b (HEAD -> master) HEAD@{3}: commit (initial): wrote a readme file

$ git reset --hard  e55063a

5.3 undo delete summary

Scenario 1: when you change the contents of a file in the workspace and want to discard the changes in the workspace directly, use the command git checkout -- file

Scenario 2: when you not only mess up the contents of a file in the workspace, but also add it to the temporary storage area, you want to discard the modification in two steps. In the first step, use the command git reset head < File >, and then return to scenario 1. In the second step, follow scenario 1

Scenario 3: when inappropriate modifications have been submitted to the version library, if you want to cancel this submission, you can use the command git reset --hard commit_id, but only if it is not pushed to the remote library

Keywords: git github bash

Added by runelore on Wed, 19 Jan 2022 08:44:29 +0200