The latest, most complete, and most detailed summary of Git study notes (the latest version of 2021)

Introduction to Git

Git is an open source distributed version control system.

What is version control?
Version control is a system that records changes in the content of one or several files in order to check the revision of a specific version in the future.

What is a distributed version control system?

Before introducing the distributed version control system, it is necessary to understand the traditional centralized version control system.

Centralized version control systems, such as CVS, Subversion, etc., have a single centralized management server that saves revisions of all files, and people working together connect to this server through the client to retrieve the latest files or Submit an update.

The most obvious disadvantage of this is the single point of failure of the central server. If there is an hour of downtime, no one can submit updates within that hour, and they will not be able to work together. If the central server's disk fails, it happens that no backup is made, or the backup is not timely enough, there is a risk of data loss. The worst case is to completely lose all historical change records of the entire project.

The client of the distributed version control system does not only extract the latest version of the file snapshot, but mirrors the code repository in its entirety. In this way, any server used for collaborative work can be restored afterwards with any mirrored local warehouse. Because every extraction operation is actually a complete backup of the code warehouse.

Refer to: Git from entry to master

Git vs SVN

Git and SVN are better, everyone has a different experience.

Git is distributed, SVN is centralized

This is the biggest difference between Git and SVN. If you can grasp this concept, you can understand most of the difference between the two. Because Git is distributed, Git supports offline work, and many operations can be performed locally, including the branch function that will be launched next. The SVN must be connected to the Internet to work properly.

• Git has many complex concepts, SVN is simple and easy to use

All developers who master both Git and SVN must admit that there are too many Git commands. Daily work needs to master add, commit, status, fetch, push, rebase, etc. If you want to master it, you must also master rebase and merge The difference, the difference between fetch and pull, etc., in addition, there are also functions such as cherry-pick, submodule, and stash, but these terms sound very confusing.

In terms of ease of use, SVN is better for novices. But on the other hand, many Git commands mean many functions. If we can master most of Git's functions and experience the mystery, we will find that we will never go back to the era of SVN.

• Git branch is cheap, SVN branch is expensive

In version management, branching is a frequently used function. Before the release of the version, a release branch is required for large-demand development, a feature branch is required, and large teams will also have development branches, stable branches, etc. In the development process of a large team, there are often requests to create branches and switch branches.

Git branch is a pointer to a certain commit, and SVN branch is a copy directory. This feature makes Git branch switching very fast, and the creation cost is very low.

And Git has a local branch, SVN does not have a local branch. In the actual development process, it is often encountered that some code is not finished, but other problems need to be dealt with urgently. If we use Git, we can create a local branch to store the unfinished code, and then return to the local after the problem is solved. The branch continues to complete the code.

For more attention to the comparison between Git and Svn, please refer to: understand | Use Git and SVN well, easily control version management

How Git works

The text is not understand, please see 16091fc2ac462b for detailed explanation of Git working principle

Git installation

• Debian/Ubuntu environment installation

If you are using Debian/Ubuntu, the installation command is:

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
> libz-dev libssl-dev
$ apt-get install git-core
$ git --version
git version 1.8.1.2

• Centos/RedHat environment installation

If the system you are using is Centos/RedHat, the installation command is:

$ yum install curl-devel expat-devel gettext-devel \
> openssl-devel zlib-devel
$ yum -y install git-core
$ git --version
git version 1.7.1

• Windows installation

Download the exe installation package from the official Git download address. Follow the installation wizard to install.

It is recommended to install Git Bash, a git command line tool.

• Mac environment installation

Download the mac installation package at the official Git download address. Follow the installation wizard to install.

Git configuration

Git comes with a git config tool to help set configuration variables that control the appearance and behavior of Git. These variables are stored in three different locations:

/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。如果使用带有 --system 选项的 git config 时，它会从此文件读写配置变量。

\~/.gitconfig 或 \~/.config/git/config 文件：只针对当前用户。可以传递 --global 选项让 Git 读写此文件。

The config file (that is, .git/config) in the Git directory of the current repository: for this repository.

Each level overrides the configuration of the previous level, so the configuration variables in .git/config will override the configuration variables in /etc/gitconfig.

On Windows systems, Git will look for the .gitconfig file in the $HOME directory (usually C:\Users\$USER). Git will also look for the /etc/gitconfig file, but only in the root directory of MSys, which is the target location selected when installing Git.

Git basic concepts

• Repository

When you go to a local project or create a git project, there will be a hidden .git subdirectory under the project directory. This directory is used by git to track and manage the repository, so don't modify it manually.

• Hash value

All data in Git calculates a checksum before storing, and then refers to it with the checksum. This means that it is impossible to change the contents of any file or directory without Git's knowledge. This function is built at the bottom of Git and is an indispensable part of the Git philosophy. If you lose information or damage files during the transfer, Git can find out.

The mechanism used by Git to calculate the checksum is called SHA-1 hash (hash). This is a string composed of 40 hexadecimal characters (0-9 and af), calculated based on the content of the file or directory structure in Git. The SHA-1 hash looks like this:

24b9da6552252987aa493b52f8696cd6d3b00373
There are many situations in which this hash value is used in Git, and you will often see this kind of hash value. In fact, the information stored in the Git database is indexed by the hash value of the file content, not the file name.

• File status

In GIt, your file may be in one of three states:

• has been modified (modified) -Modified means that the file has been modified, but it has not been saved in the database.
• staged -staged means that the current version of a modified file is marked to be included in the next snapshot.
• has been committed (committed) -Committed means that the data has been safely stored in the local database.
• Work area

Corresponding to the file status, files of different statuses are in different working areas in Git.

• working area (working )-When you git clone a project locally, it is equivalent to cloning a copy of the project locally. The workspace is the content extracted independently from a certain version of the project. These files are extracted from the compressed database of the Git repository and put on the disk for you to use or modify.
• staging area (staging) -The staging area is a file that saves the file list information that will be submitted next time, usually in the Git warehouse directory. Sometimes it is also called `'index', but in general it is called a temporary storage area.
• local warehouse (local) -Submit the update, find the files in the staging area, and store the snapshot permanently in the Git local warehouse.
• remote warehouse (remote) -The above work areas are all local. In order for others to see your changes, you need to push your updates to the remote warehouse. In the same way, if you want to synchronize other people's changes, you need to pull updates from a remote warehouse.

• Branch

Branching is to store the entire process of modification records separately, so that separate branches are not affected by other branches, so multiple different modifications can be made at the same time in the same database

The master branch (Master) mentioned earlier that master is the first branch automatically created by Git for us, also called the master branch. After the development of other branches is completed, they must be merged into master.

• Tag

Tags are used to mark specific points or commit history. They are usually used to mark the name or version number of the published version (such as publish/0.0.1). Although the tag looks a bit like a branch, the tagged commit is fixed , Can’t be changed arbitrarily, see 1.0 / 2.0 / 3.0 in the picture above

• HEAD

HEAD points to the latest commit image of the current branch

The above concepts are almost understood, so you can continue to look down.

Git commands

• Create warehouse

Clone a created warehouse:

# 通过 SSH
$ git clone ssh://[e-mail]/repo.git

#通过 HTTP
$ git clone http://domain.com/user/repo.git

Create a new local warehouse:

$ git init

• Add and modify

Add changes to the staging area:

# 把指定文件添加到暂存区
$ git add xxx

# 把当前所有修改添加到暂存区
$ git add .

# 把所有修改添加到暂存区
$ git add -A

Submit the modification to the local warehouse:

# 提交本地的所有修改
$ git commit -a

# 提交之前已标记的变化
$ git commit

# 附加消息提交
$ git commit -m 'commit message'

• Store

Sometimes, we need to work on different branches of the same project. When the branch needs to be switched, the local work has not yet been completed. At this time, the submission of changes is not rigorous, but the branch cannot be switched without submitting the code. At this time, you can use git stash to store the local modifications as a draft.

Officially called it storage, but I personally prefer to call it storage drafts.

# 1. 将修改作为当前分支的草稿保存
$ git stash

# 2. 查看草稿列表
$ git stash list
stash@{0}: WIP on master: 6fae349 :memo: Writing docs.

# 3.1 删除草稿
$ git stash drop stash@{0}

# 3.2 读取草稿
$ git stash apply stash@{0}

• Undo edit

Undo local modification:

# 移除缓存区的所有文件（i.e. 撤销上次git add）
$ git reset HEAD

# 将HEAD重置到上一次提交的版本，并将之后的修改标记为未添加到缓存区的修改
$ git reset <commit>

# 将HEAD重置到上一次提交的版本，并保留未提交的本地修改
$ git reset --keep <commit>

# 放弃工作目录下的所有修改
$ git reset --hard HEAD

# 将HEAD重置到指定的版本，并抛弃该版本之后的所有修改
$ git reset --hard <commit-hash>

# 用远端分支强制覆盖本地分支
$ git reset --hard <remote/branch> e.g., upstream/master, origin/my-feature

# 放弃某个文件的所有本地修改
$ git checkout HEAD <file>

Delete files submitted by mistake before adding the .gitignore file:

$ git rm -r --cached .
$ git add .
$ git commit -m "remove xyz file"

Undo remote modification (create a new commit and roll back to the specified version):

$ git revert <commit-hash>

Delete the specified version completely:

# 执行下面命令后，commit-hash 提交后的记录都会被彻底删除，使用需谨慎
$ git reset --hard <commit-hash>
$ git push -f

• Update and push

Update:

# 下载远程端版本，但不合并到HEAD中
$ git fetch <remote>

# 将远程端版本合并到本地版本中
$ git pull origin master

# 以rebase方式将远端分支与本地合并
$ git pull --rebase <remote> <branch>

Push:

# 将本地版本推送到远程端
$ git push remote <remote> <branch>

# 删除远程端分支
$ git push <remote> :<branch> (since Git v1.5.0)
$ git push <remote> --delete <branch> (since Git v1.7.0)

# 发布标签
$ git push --tags

• View information

Display the modified files in the working path:

$ git status

Show the difference from the last submitted version file:

$ git diff

Show submission history:

# 从最新提交开始，显示所有的提交记录（显示hash， 作者信息，提交的标题和时间）
$ git log

# 显示某个用户的所有提交
$ git log --author="username"

# 显示某个文件的所有修改
$ git log -p <file>

• Display search content:

# 从当前目录的所有文件中查找文本内容
$ git grep "Hello"

# 在某一版本中搜索文本
$ git grep "Hello" v2.5

• Branch

Add, delete and check branches:

# 列出所有的分支
$ git branch

# 列出所有的远端分支
$ git branch -r

# 基于当前分支创建新分支
$ git branch <new-branch>

# 基于远程分支创建新的可追溯的分支
$ git branch --track <new-branch> <remote-branch>

# 删除本地分支
$ git branch -d <branch>

# 强制删除本地分支，将会丢失未合并的修改
$ git branch -D <branch>

Switch branches:

# 切换分支
$ git checkout <branch>

# 创建并切换到新分支
$ git checkout -b <branch>

label

# 给当前版本打标签
$ git tag <tag-name>

# 给当前版本打标签并附加消息
$ git tag -a <tag-name>

Merge and reset

Although merge and rebase are commonly used functions of git, it is strongly recommended not to use git commands to complete this work.

Because if there is a code conflict, it is too difficult without a code comparison tool.

You can consider using various Git GUI tools.

merge:

# 将分支合并到当前HEAD中
$ git merge <branch>

Reset:

# 将当前HEAD版本重置到分支中，请勿重置已发布的提交
$ git rebase <branch>

More command reference: Three-year Git use experience & FAQ

Git branch development

Git is currently the most popular source code management tool. In order to standardize development, keep code submission records and git branch structure clear to facilitate subsequent maintenance, now standardize git related operations.

Branch naming

1. The master branch

master is the main branch, which is also the branch used to deploy the production environment to ensure the stability of the master branch. The master branch is generally merged by the develop and hotfix branches, and the code cannot be directly modified at any time

2.Develop branch

develop is the development branch, and always keep the latest completed and bug-fixed code. Generally, when developing new features, the feature branch is created based on the develop branch.

• feature branch

When developing a new feature, create a feature branch based on develop.
Branch naming: feature branches starting with feature/, naming rules: feature/user_module, feature/cart_module

• release branch

Release is a pre-launch branch. During the release test phase, the release branch code will be used as a benchmark test. When a set of features is developed, it will be merged into the develop branch first, and a release branch will be created when entering the test. If there is a bug that needs to be fixed during the testing process, it will be directly fixed and submitted by the developer in the release branch. When the test is completed, merge the release branch to the master and develop branches. At this time, the master is the latest code and is used to go online.

• hotfix branch

Branch naming: The branch at the beginning of hotfix/ is the repair branch, and its naming rule is similar to the feature branch. When an urgent problem occurs online, it needs to be repaired in time. Use the master branch as the baseline to create a hotfix branch. After the repair is completed, it needs to be merged into the master branch and the develop branch.

For more development specifications, please refer to: The most comprehensive Git branch development specification manual on the entire network | Master these 10 specifications and easily get Git!

Git these advanced usages, just use it if you like!

Git submission specification

Why do we need norms?

Irregularities do not form a circle, and so does programming.

If you have a project that you write by yourself from start to finish, then you can write it whatever you want, and no one can interfere with you. But if in teamwork, everyone flaunts their individuality, then the code will be a mess, and a good project will be ruined. Whether it is development or future maintenance, it will be a disaster.

At this time, someone proposed why not a unified standard, and everyone followed this standard. As a result, code tools such as ESLint and JSHint have sprung up and become essential products for project construction.

The Git Commit specification may not be so exaggerated, but if you see a large section of horrible Commits when the version is rolled back, I am afraid you will be very upset. Therefore, strictly abide by the norms and benefit others and yourself.

For details, please refer to: Git submission specifications that you might ignore

Git usage skills

Only when you encounter problems do you realize the benefits of skills!

Common corporate workflow

Mainly introduce the Git workflow commonly used in enterprises!

• Git Flow
• Trunk branch
• Stable branch
• Development branch
• Patch branch
• Modify branch

Github Flow

• Create branch
• Add commit
• Submit a PR request
• Discuss and evaluate code
• Deployment detection
• Merge code

Gitlab Flow

• With production branch
• With environmental branch
• With release branch

Best Practices for Daily Use

Git usage and methods that should be followed in daily work!

• Use command line instead of graphical interface
• Use the command line to operate, concise and efficient
• The submission should state as much as possible the submitted amendments
• Distinguish subject and body content, separated by blank lines
• Subject generally does not exceed 50 characters
• The length of each line of body is controlled at 72 characters
• There is no need to end with a period or dot at the end of the subject
• body is used to explain in detail what was done in this submission
• Use .gitignore files to exclude useless files
• Template files can be used, and then modified according to the actual project
• Development mode based on branch or fork
• Don't develop directly on the main branch
• Function development and problem repair on the newly created branch
• Use release branches and tag tags for version management
• Use the release branch to release code and version maintenance (release/1.32)
• Use tag to mark the version (A-large feature function. B-small feature function. C-fix bugs only)

Summary of commonly used commands

Just remember everyday use 6 command on it.

# 工作区 -> 暂存区
$ git add <file/dir>

# 暂存区 -> 本地仓库
$ git commit -m "some info"

# 本地仓库 -> 远程仓库
$ git push origin master  # 本地master分支推送到远程origin仓库 

# 工作区 <- 暂存区
$ git checkout -- <file>  # 暂存区文件内容覆盖工作区文件内容

# 暂存区 <- 本地仓库
$ git reset HEAD <file>   # 本地仓库文件内容覆盖暂存区文件内容

# 本地仓库 <- 远程仓库
$ git clone <git_url>        # 克隆远程仓库
$ git fetch upstream master  # 拉取远程代码到本地但不应用在当前分支
$ git pull upstream master   # 拉取远程代码到本地但应用在当前分支
$ git pull --rebase upstream master  # 如果平时使用rebase合并代码则加上

# 工作区 <- 本地仓库
$ git reset <commit>          # 本地仓库覆盖到工作区(保存回退文件内容修改)
$ git reset --mixed <commit>  # 本地仓库覆盖到工作区(保存回退文件内容修改)
$ git reset --soft <commit>   # 本地仓库覆盖到工作区(保留修改并加到暂存区)
$ git reset --hard <commit>   # 本地仓库覆盖到工作区(不保留修改直接删除掉)

For more introduction to the use of Git, please refer to: Learn these 11, you are not far from the Git God!

Git knowledge system dynamic update see here