Detailed explanation of Git version control tool

1. Version control

1.1. Understanding version control (version control)

What is version control?

The English version control is Version control;
It is a standard practice for maintaining engineering blueprints, and can track the process of engineering blueprints from birth to finalization;
Version control is also a software engineering technique to ensure that the same program files edited by different people are synchronized during the software development process;

To put it simply, version control can help programmers perform a series of operations such as code tracking, maintenance, and control in software development .

1.2, the function of version control

For our daily development, we often face the following problems, which can be solved well through version control:

Storage management for different versions :

A project will continue to iterate the version to fix some previous problems, add new functions, requirements, and even refactor the project;
If we manually maintain a series of project backups, it is a nightmare;

Backup maintenance of major versions : For many major versions, we will perform backup management;
restore the previous project version : when some serious problems occur during our development process, we want to restore the previous operation or return to a previous version;
Record every bit of the project : If we need to record every function modification, bug fix, and new requirement change, version control can be solved very well;
code merging developed by multiple people : there are usually multiple people in the project Development, merging multi-person code, and better handling when conflicts arise;

1.3, the history of version control

The prehistoric era of version control (no version control): people usually manage by means of file backup, and then use the diff command to compare the differences between the two files; CVS
(Concurrent Versions System)

The first version control tool to be used on a large scale was born in 1985;
Realized by Professor Dick Grune of VU University in Amsterdam, the Netherlands, it can be regarded as the predecessor of SVN (SVN appeared to replace CVS).

SVN（Subversion）

Because its command-line tool is called svn, it is often referred to as SVN for short;
SVN was funded and developed by CollabNet in 2000. The purpose is to replace CVS, and a lot of optimizations have been made to CVS;
Like CVS, SVN is also a centralized version control tool;
SVN has a very high usage rate in early company development, but it has been replaced by Git;

Git (work by Linus)

In the early days, the Linux community used BitKeeper for version control;
But for some reasons, BitKeeper wants to take back the free license to the Linux community;
So Linus spent about a week developing Git to replace BitKeeper;
Linus completed the core design of Git, after which Linus retired and handed over Git to Junio C Hamano, another main Git contributor;

1.4. Centralized version control

Both CVS and SVN are centralized version control systems (Centralized Version Control Systems, referred to as CVCS)

Their main feature is a single centrally managed server, which holds revisions of all files;
Collaborative developers connect to this server through the client, take out the latest files or submit updates;

There are many benefits to this approach, not least the fact that everyone can see to some extent what everyone else on the project is doing compared to old-fashioned local management.

But centralized version control also has a core problem: the central server cannot fail :

If the downtime is one hour, no one can submit updates during this hour, and they cannot work together;
If the disk where the central database is located is damaged and there is no proper backup, you will undoubtedly lose all data;

1.5. Distributed version control

Git is a distributed version control system (Distributed Version Control System, referred to as DVCS)

The client does not only extract the latest version of the file snapshot, but completely mirrors the code warehouse, including the complete history;
In this way, if any server used for collaborative work fails , it can be restored with any mirrored local warehouse afterwards ;
Because each clone operation is actually a complete backup of the code repository ;

2. Git installation

To use Git on the computer, we need to install Git first:

Git's official website: Git - Downloads
Download Git according to your operating system;

In the window operating system, it can be installed globally according to the default configuration;

3. Difference between Bash – CMD – GUI

Bash, one of the Unix shells, is used as the default shell on both Linux and Mac OS X.

Git Bash is a shell, a command line tool under Windows, which can execute Linux commands;
Git Bash is based on CMD , adding some new commands and functions on the basis of CMD ;
Therefore, it is recommended that it is more convenient to use Bash when using ;

Git CMD

The command line prompt (CMD) is a command line interpreter on the Windows operating system;
When you install git on Windows and are used to using the command line, you can use cmd to run git commands;

Git GUI

Basically for those who don't like coding with a black screen (i.e. the command line);
It provides a GUI to run git commands;

4. Git configuration

4.1, Git configuration classification

Now that Git is installed on your system, you will need to do a few things to customize your Git environment:

Each computer only needs to be configured once , and the configuration information will be retained when the program is upgraded;
You can modify them at any time again by running the command ;

Git comes with a git config tool to help set configuration variables that control Git's appearance and behavior:

/etc/gitconfig file : Contains common configuration for every user on the system and their repositories
- If you take the --system option when executing git config , it will read and write the configuration variables in the file;
- Since it is a system configuration file, you need administrator or superuser privileges to modify it. (Usually not modified during development)
~/.gitconfig or C/user/coderwhy/.gitconfig file : only for the current user (commonly used)
- You can pass the --global option to make Git read and write this file, which will take effect for all repositories on your system;
The config file in the Git directory of the current warehouse (ie. git/config) : for this warehouse
- You can pass the --local option to force Git to read and write this file, although it is used by default;

4.2, Git configuration options

After installing Git, the first thing to do is to set up your username and email address.

This is very important, because every Git commit will use this information , they will be written in every commit of yours , and cannot be changed;
If the --global option is used , then the command only needs to be run once , because Git will use that information no matter what you do on the system afterwards;

git config --global user.name "coderwhy"

git config --global user.email "[email protected]"

Check the current configuration information: git config --list

View a certain configuration information (for example, view user name)

git config user.name

4.3, Git alias (alias)

Git doesn't automatically infer the command you want when you type some commands:

If you don't want to enter the complete Git command every time, you can easily set an alias for each command through the git config file .

git config --global alias.co  checkout
git config --global alias.br  branch
git config --global alias.ci  commit
git config --global alias.st  status

5. Get the Git repository – git init/git clone

We need a Git to manage the source code, so we also need a Git repository locally.

There are usually two ways to get a Git project repository:

Method 1 : Initialize a Git warehouse , and add the files of the current project to the Git warehouse (currently, many scaffolding will create a Git warehouse by default when creating a project);
Method 2 : Clone an existing Git repository from other servers (we usually need to do this operation on the first day when we arrive at the company);

Method 1: Initialize the Git repository

This command will create a subdirectory named .git, which contains all the necessary files in the Git repository you initialized. These files are the core of the Git repository;
However, at this time, we just did an initialization operation, and the files in your project have not been tracked yet;

git init

Method 2: From Git remote warehouse

git clone https://github.com/coderwhy/hy-react-web-music.git

6. Status division of files

Now we already have a Git repository on our computer:

In actual development, you need to hand over certain files to this Git repository for management;
And we will modify the content of the file later. When a certain goal is achieved, if we want to record this operation, we will submit it to the warehouse;

Then we need to divide the file into different states to determine whether the file is already under the management of the Git repository:

Untracked : By default, the files under the Git warehouse are not added to the Git warehouse management, we need to use the add command to operate;
Tracked : The files added to the Git warehouse management are in the tracked state, and Git can perform various tracking management on them;

Tracked files can be subdivided into state divisions:

staged : the state of the file in the staging area;
Unmodified : commit command, which can submit files in staged to Git warehouse
Modified : After a file is modified, it will be in Modified state;

While working, you can selectively put these modified files into the staging area;

Then commit all staged changes, and so on;

7. Git operation flow chart

8. Check the status of the file - git status

We create a new file in the directory with the Git warehouse and check the status of the file:

git status

Untracked files : Untracked files

Untracked files mean Git didn't have those files in a previous commit;
Git will not automatically track it unless you tell it explicitly "I need to track this file";

We can also view more concise status information:

git status –s
git status --short

The left column indicates the status of the staging area, and the right column indicates the status of the work area;

9. Add files to the temporary storage area – git add

Tracking new files command: Use the command git add to start tracking a file.

git add aaa.js

Track modified file command : If we have tracked a certain file, the modified file needs to be added to the temporary storage area at this time;

Add all files to the temporary storage area through git add .:

git add .

10. git ignores files

Generally, we always have some files that don't need to be managed by Git, and we don't want them to always appear in the list of untracked files.

Usually these are automatically generated files , such as log files, or temporary files created during compilation, etc.;
We can create a file called .gitignore that lists patterns of files to ignore;

In actual development, this file usually does not need to be created manually, just add your own ignored content when necessary;

For example, the right side is the ignore file automatically created by the created Vue project:

Including some files and folders that do not need to be submitted;
Include local environment variable files;
Include some log files;
Including files automatically generated by some editors;

11. File update submission – git commit

The staging area is now ready to commit.

Before each submission, use git status to see if all the files you need have been temporarily stored;
Then run the submission command git commit;
You can add the -m option after the commit command to put the commit information and the command on the same line;
- git commit –m "commit message"

If we modify the add operation of the file, and the commit operation is a bit cumbersome, then the two commands can be used in combination:

git commit -a -m "modified the bbb file"

12. Git checksum

All data in Git is checksummed before being stored, and then referenced as a checksum.

The mechanism Git uses to calculate checksums is called a SHA-1 hash (hash, hash);
This is a string of 40 hexadecimal characters (0-9 and af), calculated based on the contents of a file or directory structure in Git;

13. View the commit history – git log

After submitting several updates, or cloning a project, sometimes we want to view all historical commit records.

At this time we can use the git log command:

By default, without passing in any parameters, git log will list all commits in chronological order, with the most recent update at the top;
This command lists each commit's SHA-1 checksum, author's name and email address, commit time, and commit description;

git log

git log pretty= oneline

git log --pretty=oneline --graph

14. Version rollback – git reset

If we want to roll back the version, we need to know which version we are in first: Git records the current version through the HEAD pointer.

HEAD is a pointer to the current branch reference, which always points to the last commit on that branch;
The simplest way to think of HEAD is as a snapshot of the last commit on that branch;

We can change the current version of Git to point to through HEAD:

The previous version is HEAD^ , and the previous version is HEAD^^ ;
If it is the last 1000 versions, we can use HEAD~1000 ;
We can specify a commit id;

git reset --hard HEAD^
git reset --hard HEAD~1000 
git reset --hard 2d44982 （可以不用写完id，写id的前几位也行，前提是保证这几位id是唯一的，如果不是在继续多写几位，直至唯一）

But there will be a problem at this time. If we repent at this time and want to return the version before the downgraded version, we will use the git log command at this time, and we will find that the latest id is the id of the downgraded version. Our previous version id is missing. At this time, we should use the git reflog command, which records the id of each version in great detail, and also records the operation steps.

git reflog

15. Remote warehouse

15.1. What is a remote warehouse?

What is a remote warehouse (Remote Repository)?

Currently our code is stored in a local warehouse, which means we are only doing local operations;
In real development, we are usually developed by multiple people, so we will share the managed code to the remote warehouse;

So how to create a remote warehouse?

The remote warehouse is usually built on a certain server (of course, it is also possible locally, but it is difficult to share locally);
So we need to build a remote warehouse on the Git server;

Currently we have the following ways to use the Git server:

Use third-party Git servers: such as GitHub, Gitee, Gitlab, etc.;
Build a Git service on your own server;

15.2. Verification of remote warehouse

What are the common remote warehouses? There are currently three popular ones:

GitHub：https://github.com/
Gitee：https://gitee.com/
Build Gitlab yourself: http://152.136.185.210:7888/

For private warehouses we want to operate, the remote warehouse will verify our identity:

If there is no verification, it is very dangerous for anyone to operate the warehouse at will;

At present, there are two main methods of Git server verification:

Method 1: Credential Storage based on HTTP ;
Method 2: SSH-based key ;

15.3. Verification of Remote Warehouse – Credentials

Because the HTTP protocol itself is a stateless connection, each connection requires a username and password:

If you do this every time, it will be very troublesome;
Fortunately, Git has a credential system to handle this;

Here are some options for Git Credential:

Option 1: All are not cached by default. Every time you connect you will be asked for your username and password;
Option two: "cache" mode will store credentials in memory for a certain period of time. Passwords are never stored on disk and are cleared from memory after 15 minutes;
Option 3: "store" mode will store the certificate in plain text on the disk, and it will never expire;
Option 4: If you're on a Mac, Git also has an "osxkeychain" mode that caches the credentials in your system user's keychain (encrypted);
Option 5: If you are using Windows, you can install a helper tool called "Git Credential Manager for Windows"; available at GitHub - microsoft/Git-Credential-Manager-for-Windows: Secure Git credential storage for Windows with support for Visual Studio Team Services, GitHub, and Bitbucket multi-factor authentication. Download. (This plugin will be installed by default when we install git)

Use the following command to check whether it is installed

git config credential.helper
// 输出 manager-core，证明安装成功

15.4. Authentication of remote warehouse – SSH key

Secure Shell (Secure Shell Protocol, SSH for short) is an encrypted network transmission protocol that can provide a secure transmission environment for network services in an insecure network.
SSH implements authentication with asymmetric encryption.
- For example, one method is to simply encrypt the network connection using an automatically generated public-private key pair, and then use password authentication to log in;
- Another method is to manually generate a pair of public key and private key, and authenticate through the generated key, so that you can log in without entering a password;
- The public key needs to be placed in the computer to be accessed, and the corresponding private key needs to be kept by the user;
If we access the Git repository through SSH, we need to generate the corresponding public and private keys:

// 生成方式一
ssh-keygen -t ed25519 -C “your email"

// 生成方式二
ssh-keygen -t rsa -b 2048 -C “your email"

Note: The .pub suffix file is the public key. We need to copy the contents of this public key and add it to github or other third-party open source git platforms. Then we can use ssh authentication instead of login authentication up.

15.5. Manage remote servers

View the remote address : For example, the code we cloned from GitHub earlier has its own remote warehouse:

git remote

git remote –v : -v is an abbreviation for --verbose (verbose)

Add a remote address : We can also continue to add a remote server (let the local warehouse and the remote server warehouse establish a connection):

git remote add <shortname> <url>

git remote add gitlab http://152.136.185.210:7888/coderwhy/gitremotedemo.git

Rename the remote address : git remote rename old name new name

Remove the remote address : git remote remove name

16. Problems caused by git pull

16.1. Upstream branch of local branch (tracking branch)

Question 1: The current branch does not have a track branch

Reason: The current branch is not tracked with the remote origin/master branch

In the absence of tracking, when we directly execute the pull operation, we must specify which branch in which remote warehouse to get the content from;

git pull 配置的远程仓库名 远程分支名

If we want to execute git fetch directly, there is a prerequisite: a tracking branch must be set for the current branch:

Before setting up the upstream branch, use the git fetch command to let the local warehouse know which branches the remote warehouse has

git branch --set-upstream-to=origin/master

16.2. Refuse to merge irrelevant histories

Problem 2: When merging remote branches, refuse to merge irrelevant histories

Reason: We merged two unrelated branches:

Git refusing to merge unrelated histories on rebase - Stack Overflow

To put it simply: in the past, git merge allowed two branches with no common base to be merged, which led to a consequence: a newly created project may be merged with a lot of unnecessary history by an unsuspecting maintainer, to an already In existing projects, this command is currently corrected, but we can still escape this limitation with the --allow-unrelated-histories option to merge two separate projects;

git merge --allow-unrelated-histories

17. Interaction of remote warehouses

clone code from remote repository: clone the repository into the newly created directory;

git clone http://152.136.185.210:7888/coderwhy/gitremotedemo.git

Push the code to the remote warehouse: push the code of the local warehouse to the remote warehouse;

By default, the current branch (such as master) is pushed to the origin remote warehouse ;

git push (this must ensure that the current branch name is the same as the remote branch name, otherwise an error will be reported. This requires specifying the detailed branch name)
git push origin master

fetch code from remote warehouse: get the latest code from remote warehouse

By default, the code is obtained from origin;
- git fetch
- git fetch origin master
After getting the code, it is not merged into the local warehouse by default, we need to merge it through merge ;
- git merge
- git merge origin/master
- Note: At this time, you will find out why the remote warehouse branches specified by fetch and merge are different. This is fixed and just keep in mind.

Pull code from remote warehouse: the above two operations are a bit cumbersome, we can operate with one command

git pull

The above command is equivalent to

git fetch + git merge(rebase)

18. Actual company development process

Situation 1: After you arrive at the company, the company already has projects and remote warehouses

git clone project address
develop
- git add .
- git commit -m "commit"
- git pull -> git fetch/git merge
- git push

Situation 2: Develop a brand new project (built by you)

Create a remote warehouse

Option One:
- git clone project address
- Start building the entire project in the clone folder
- git add .
- git commit -m ""
- git push
Option II:
- Create a local repository and build a local project
- git remote add origin project address
- git branch --set-upstream-to=origin/master
- git fetch
- git merge --allow-unrelated-histories
- git push

19. Problems with git push

When we use the git push command (the remote warehouse address must be configured before use), sometimes the branch name of our local warehouse is different from the branch name of the remote warehouse. At this time, we will report an error even if we set the upstream branch. We must use the git push command to specify the detailed local branch name and remote branch name so that they can be related.

git push origin local branch name : remote branch name

Note : This origin is the name we specified when adding the remote warehouse address, or we can also create a new branch with the same name as the remote warehouse branch to push

At this time, we have a problem, that is, we have set up the upstream branch, so we can use the git push command directly without parameters? Why, this way doesn't work? The occurrence of this problem is related to the configuration of git's default push mode parameters.

git config push.default parameter

The current parameter in this is simple , which means that when we directly use git push and omit the following parameters, at this time, git will check whether there is the same branch name in the remote warehouse, and if not, it will report an error. Through this parameter, we can know that git does not use the upstream branch we set at all during the push operation, and of course it will not work. If we want to use the upstream branch we set, we only need to change the simple parameter inside to upstream at this time , so we can use git push, and we don’t need to keep up with any parameters later, and there will be no error reporting problem.

git config push.default upstream

Note: This setting only takes effect for the current project. If you want to take effect globally, you must follow the --global parameter

For a more detailed description of push.default, please refer to the documentation: Git - git-config Documentation , you can also use the following command to view git config --help

20. Common open source protocols

21. Git tag (tag)

(1) Create tags

For major versions, we often put a label to indicate its importance:

Git can tag a commit in the repository history;
Typically people will use this feature to tag release nodes ( v1.0 , v2.0 , etc.);

Create tags:

Git supports two types of tags: lightweight and annotated ;
Annotation label: through the -a option, and add additional information through -m ;

git tag v1.0

git tag -a v1.1 -m "附注标签"

By default, the git push command does not transfer tags to remote warehouse servers.

After creating the tags, you must explicitly push the tags to the shared server. When other people clone or pull from the warehouse, they can also get your tags;

// 推送单个标签
git push origin v1.0

// 推送所有标签
git push origin --tags

(2) Delete and check out tag

Delete local tags:

To delete a tag on your local repository, you can use the command git tag -d <tagname>

Delete remote tag:

To delete a remote tag we can pass git push <remote> –delete <tagname>

Check out tags:

If you want to view the version of the file pointed to by a certain label, you can use the git checkout command;
Usually when we check out the tag, we will also create a corresponding branch (the branch will be learned later);

view all tags

git day

22. Git commit object (Commit Object)

Almost all version control systems support branching in some form.

Using branches means that you can separate your work from the main line of development so that it does not affect the main line of development.

When committing, Git saves a commit object:

The commit object will contain a pointer to a snapshot of the staging content;
The submission object also contains the author's name and email address, the information entered when submitting, and a pointer to its parent object;
- The submission object generated by the first submission has no parent object, and the submission object generated by the normal submission operation has a parent object;
- Commit objects generated by merging multiple branches have multiple parent objects;

23. Git master branch

Git branches are essentially just mutable pointers to commit objects.

The default branch name of Git is master. After multiple submissions, you actually already have a master branch pointing to the last submission object;
The master branch is automatically moved on each commit;

Git's master branch is not a special branch.

It is completely indistinguishable from other branches;
The reason why almost every warehouse has a master branch is because the git init command creates it by default, and most people don't bother to change it;

24. Git creates branches

How does Git create new branches?

Very simple, it just creates a new pointer for you that can be moved;

For example, to create a testing branch, you need to use the git branch command:

git branch testing

So, how does Git know which branch it is currently on?

It is also very simple, it is also through a special pointer called HEAD ;

git checkout testing

25. Git branch submission

If we point to a certain branch and commit on this branch:

You can also switch back to the master branch and continue developing:

26. Create branches and switch at the same time

Switch to the past while creating a new branch

Usually we switch over immediately after creating a new branch;
This can be done with one command: git checkout -b <newbranchname> ;

27. Why do you need to use branches?

Let's look at a simple example of branch creation and branch merging. You may use a similar workflow in actual work.

Develop a project and develop it on the default branch master;
Realize the functional requirements of the project and submit continuously;
And when a major version is completed, release the version with a tag v1.0.0;

Continue to develop subsequent new features. At this moment, you suddenly receive a call saying that there is a very serious problem that needs to be repaired urgently. You will deal with it as follows:

Switch to tag v1.0.0 and create a branch hotfix;

To create a new branch and switch to that branch at the same time, you can run a git checkout command with the -b parameter :

git checkout –b hotfix

28. Branch development and merging

Develop and fix bugs on the branch:

We can continue development work or fix bugs on the created hotfix branch;
After completing the work to be done, re-label a new tag v1.0.1;

Switch back to the master branch, but at this time the master branch also needs to fix the bug just now:

So we need to merge the master branch and the hotfix branch;

git checkout master
git merge hotfix

29. View and delete branches

If we want to view all current branches, we can use the following command:

git branch          # View all current branches
git branch –v          # View the last commit at the same time
git branch --merged          # View all branches merged into the current branch
git branch --no-merged         # View all branches not merged into the current branch

If we no longer need some merged branches, we can remove them:

git branch –d hotfix # delete the current branch

git branch –D hotfix #Forcibly delete a certain branch

30. Git workflow (git flow)

Due to the convenience of using branches on Git, many Git workflows have been generated:

In other words, at different stages of the entire project development cycle, you can have multiple open branches at the same time;
You can periodically merge some topic branches into other branches;

For example, the following workflow:

master as the main branch;
develop as a development branch, and when there is a stable version, it is merged into the master branch;
A topic is developed as a branch of a theme or function or feature, and is merged into the develop branch after the development is completed;

More common git flow

31. Remote branches of Git

A remote branch is also a branch structure:
- Named in the form of <remote>/<branch> ;
If we just cloned the code, the structure of the branch is as follows:
If someone else modifies the code, the remote branch structure is as follows:
- You need to get the latest remote branch submission information through fetch;

32. Management of remote branches

Operation 1: Push the branch to the remote

When you want to share a branch publicly, you need to push it to a remote warehouse with write permissions;
Run git push <remote> <branch> ; (when the remote warehouse does not have the branch, it will be created automatically)
- git push origin <branch>

Operation 2: Track remote branches

When cloning a repository, it usually automatically creates a master branch that tracks origin/master;
You can set up other tracking branches if you wish, which can be done by running
- git checkout --track <remote>/<branch>

If the branch you're trying to checkout (a) doesn't exist and (b) just happens to have a remote branch with a matching name, then Git will create a tracking branch for you;

Method 1: git checkout --track <remote>/<branch>

Method 2: git checkout <branch>

Operation 3: Delete the remote branch

If a remote branch is no longer used and we want to delete it, we can run the git push command with the --delete option to delete a remote branch.

git push origin --delete <branch> (--delete can also be abbreviated as -d)

merge conflict

After we get the branch content from the Git remote warehouse through pull, it will automatically merge (merge), but not all cases can be merged normally, and in some cases, conflicts will occur when merging:

There will be no conflicts when different files are merged, but conflicts may occur when the same files are merged. At this time, we can manually modify the conflicting parts to solve the problem.

33. Git rebase usage

There are two main ways to integrate changes from different branches in Git: merge and rebase .

What is rebase?

In the example above, you can extract the patches and modifications introduced in C4 and apply them once on top of C3;
In Git, this operation is called rebase (rebase);
You can use the rebase command to move all the changes committed to a branch to another branch, just like "replaying";
How to understand the word rebase?
- We can understand it as changing the base of the current branch;
- For example, if you execute rebase master on the branch experiment, you can change the base of the experiment to master

// 切换分支
git checkout experiment 
// 合并master
git rebase master

34. The principle of rebase

How does rebase work?

Its principle is to first find the nearest common ancestor C2 of the two branches (ie, the current branch experiment, the target base branch master of the rebase operation);
Then compare the previous submissions of the current branch relative to the ancestor, extract the corresponding modification and save it as a temporary file;
Then point the current branch to the target base C3;
Finally, the modifications previously saved as temporary files are applied sequentially;

We can perform the merge operation on master again:

// 切换到master分支
git checkout master

// 合并分支，这样head指针，就会指向experiment
git merge experiment

35. Choice of rebase and merge

How to choose between rebase and merge in development?
In fact, rebase and merge are different approaches to Git history:
- Merge is used to record all the history of git , so the history of branches is intricate and all are recorded;
- Rebase is used to simplify the history , simplify the history of the two branches, and make the whole history more concise;
After understanding the underlying principles of rebase, you can choose merge or rebase according to your specific scenario.
NOTE: There is a golden rule for rebase: never use rebase on the master branch
- If rebase is used on main, it will cause a large amount of commit history to be different in the main branch;
- When multiple people develop, other people are still in the original main, which will have a big change in the submission history

36. Git common command cheat sheet

Note : The command to delete a remote branch or label is wrong, the correct one should be

git push <remote> –delete <branch/tagname>