Detailed explanation of git at work

Overview

I have always wanted to write git notes, but I don't have time to do it, I can only fill it up slowly when I am free;

There is no doubt that git is currently the best distributed version control tool, and there is no one; as a code farmer, git already a necessary skill, and many excellent communities are based on git do version control; For example, the world's largest program ape same-sex dating site github ;

There are many ways to use git, we can use git bash this command-line mode, you can also use TortoiseGit or SourceTree such a GUI tool, these GUI tools can also provide a variety of functions; but personally still prefer the command line, The first is that the compulsory standard is relatively high, and the second is that most GUI software only implements a subset of all the functions of git to reduce the difficulty of operation; all git commands can be executed in the command line mode, although most of them are Not used in development;

Installation and configuration

The installation of git is also relatively simple, git download official website find the version corresponding to the operating system, and just next all the way;

Git GUI Here and Git Bash Here will appear in the shortcut menu; we can open Git Bash and enter in the command line interface:

$ git --version

  git version 2.18.0.windows.1

git the version number of 061000a654a508 appears, it means that our git has been installed successfully; all of our subsequent operations are based on Git Bash ;

After the installation is complete, we can use git to get the git upgrade:

$ git clone git://git.kernel.org/pub/scm/git/git.git

Initial configuration

git comes with a git config tool to help set the configuration variables of the appearance and behavior of git
After installing git , the first thing that should be done is to set the username and email address;

$ git config --global user.name "Your Name"
$ git config --global user.email "[e-mail]"

Because git is a distributed management system, git will record the user name and mailbox, and cannot be modified; it should be noted that the --global option only needs to be run once, and then no matter what you do on the system, the global configuration will be used; Of course, you can also specify a different user name and email address for a warehouse.

text editor

git will use the default editor of the operating system, usually vim . If you want to use another editor, you can set it like this:

$ git config --global core.editor emacs

Check configuration items

If you want to check the configuration items, you can use the git config --list command to list all the configurations that can be found in git

$ git config --list

  core.symlinks=false
  core.autocrlf=true
  core.fscache=true
  color.diff=auto
  color.status=auto
  ...

You can also use git config <key> to check the configuration of a certain item:

$ git config user.name

Git repository

The repository is also known as a warehouse, and its English name is repository . It can be understood that the repository is a directory. All files in this directory can be managed by git. Every file addition, deletion, and change will be tracked by git, so that it can be tracked at any time. Find file records;

There are two ways to create a repository. The first is to git init the current folder into a warehouse that can be managed by git through 061000a654a604; the second is to directly clone an existing warehouse;

Create a repository

Enter an empty directory, open bash through the right-click menu and enter:

$ git init

After executing init, there will be an .git hidden folder of 061000a654a637 in the folder. If you don't see this folder, you can set the folder attributes; this directory is used by git to record the file version, and generally will not be modified;

At this time, we just made an initialization action, the files in the directory have not been tracked, you can use the git add <file> command to track the files, and then execute the commit submission;

$ git add reademe.txt 
$ git commit -m "首次提交的内容"      

git add command is to add files to the warehouse. You can add multiple files at once, just add the file name after the parameter and press the tab key; you can also add all files at once, using the git add * or git add --all command;

Clone warehouse

If you want to obtain a copy of an existing git repository and contribute your own strength to an open source project, you must use the git clone <url> command at this time:

$ git clone https://gitlab.com/Scorpio-nan/myproject

This will clone the remote warehouse to the local and create a git warehouse of myproject

git supports a variety of data transmission protocols. The above example uses the https:// protocol, but you can also use the git:// protocol or the SSH transmission protocol;

View file status

git directory have only two statuses: tracked or untracked. Tracked files refer to those files that have been included in version control, and they have their records in the log. After working for a period of time, their The status may be unmodified, modified or put into the staging area.

To check which files are in what state, you can use the git status command; now, we create a new README.txt file under the directory, if this file does not exist before, use git status will see an untracked file;

$ git status

  On branch master
  No commits yet
  Untracked files:
    (use "git add <file>..." to include in what will be committed)
          README.txt
  nothing added to commit but untracked files present (use "git add" to track)

In the file status above, we can see that the newly created README file appears under Untracked files ; it means that the file has not been included in the version control of git

add files

Use the git add <key> command to start tracking a file;

$ git add README.txt

Now, when we check the file status again, we can see that the file README.txt has been tracked and is in a temporary storage state;

$ git status

  On branch master
  No commits yet
  Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
          new file:   README.txt

As long as Changes to be committed , it means it has been temporarily stored.

Temporary storage of modified files

Now, let's modify a file that has been tracked; README.txt , and check the status of the file;

$ git status

  On branch master
  No commits yet
  Changes to be committed:
    (use "git rm --cached <file>..." to unstage)
          new file:   README.txt
  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

Changes not staged for commit indicates that the content of the file has changed, but it has not been added to the temporary storage area. To update to the temporary storage area, you need to execute the git add command again;

git status command is very detailed, but the detailed information is a bit cumbersome. We can also use the git status -s or git status --short command to view the status;

$ git stauts -s

  AM README.txt

• ?? represents a newly added file that has not been tracked;
• A represents a file newly added to the temporary storage area;
• M represents the modified file;
  There are two positions where M can appear. The left side indicates that the file has been modified and placed in the temporary storage area; the right side indicates that the file has been modified, but has not been added to the temporary storage area;

Ignore files

Sometimes, we must put the files git , but cannot submit them; in this case, we can create a .gitignore , list the files that need to be ignored, and git will do it every time we operate Ignore these files;

For the complete .gitignore configuration, see gitignore ;

When we are developing the vue project, if we use git to manage the version, we can add the following content .gitignore

dist
node_modules

When we add and submit each time, git will automatically ignore the development dependencies of the project;

View modification

git status command can view the status of the file, but it cannot fully view what has been modified in the file. At this time, we can use the git diff command to view the specific changes in the file;

$ git diff

  diff --git a/README.txt b/README.txt
  index 4632e06..5737925 100644
  --- a/README.txt
  +++ b/README.txt
  @@ -1 +1 @@
  -123456
  \ No newline at end of file
  +随便写点什么;
  \ No newline at end of file

This command compares the difference between the current file in the working directory and the snapshot of the staging area, that is, the changes that have not been temporarily saved after modification

Submit an update

Before submitting an update each time, it is best to use git status check the file status first, and be sure to confirm that there are any modified or newly created files that have not been git add , otherwise the changes of these files will not be recorded when submitting;

$ git commit -m "首次提交 2019年9月6日11:25:11"

  [master (root-commit) 424efbe] 首次提交 2019年9月6日11:25:11
   2 files changed, 4 insertions(+)
   create mode 100644 .gitignore
   create mode 100644 README.txt

git commit command, -m is the log of this submission, similar to the svn , you can enter anything, but it is better to be meaningful, so that we can easily find the modified record from the history record;

Delete Files

To git , it must be removed from the staging area and then submitted; you can use the git rm <file> [param] command to complete the operation;

If you simply delete files manually from the directory, you will see Changes not staged for commit git status

$ git status

  On branch master
  Changes not staged for commit:
    (use "git add/rm <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
          deleted:    test.txt
  no changes added to commit (use "git add" and/or "git commit -a")

Then run git rm record the removal operation

$ git rm test.txt

  rm 'test.txt'

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

It will not be included in version management the next time it is submitted;

rm can be a single file or an entire folder, but it should be noted that if you delete a folder, you need to add the -r parameter at the end:

$ git rm dir -r

View history

After submitting multiple updates, we can use the git log <key> command to view the commit log of the current project;

$ git log
  commit d9fcc0f21f254c59f13d302f77f608d573c51e09 (HEAD -> master)
  Author: Hope <[e-mail]>
  Date:   Fri Sep 6 13:38:53 2019 +0800
      45546

  commit 379abcbace5c87823c3ab51ff54efcd20deaa487
  Author: Hope <[e-mail]>
  Date:   Fri Sep 6 11:30:30 2019 +0800
      添加修改后的文件 2019年9月6日11:30:29

  commit 424efbec89f2ebc759866b03053bcf074b33b453
  Author: Hope <[e-mail]>
  Date:   Fri Sep 6 11:25:12 2019 +0800
      首次提交 2019年9月6日11:25:11

If no parameters are used by default, git log will list all the updates according to the submission time, and the most recent update will be at the top;

git log has many options to choose from, here are some commonly used options;

• git log -p -2 -p used to display the difference of each submission; you can also add -2 to display only the last two submissions;
• git log --pretty=oneline --pretty can be specified to display the submission history in a different format from the default; oneline displays each submission on a line; in addition, short , full and fuller can be used;
• git log --stat --stat View summary statistics for each submission;
• git log --shortstat --shortstat Only display the last number of rows in --stat Modify add and remove statistics
• git log --name-only --name-only Only show the modified file list after submitting the information
• git log --name-status --name-status displays a list of new, modified, and deleted files
• git log --graph --graph displays the branch and merge history represented by ASCII graphics

Undo operation

At any stage, we may need to undo certain operations; now, we README.txt , and use the git status command to check:

$ 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")

git will tell us that the file has been modified, and this modification has not been added to the temporary storage area; and it will prompt that you can use the git add <file>... update operation and git checkout -- <file>... discard the modification;

Next, after using the undo operation on the file, check the file status again (you can also manually open the README.txt file and view the file content):

$ git checkout README.txt
$ git status

  On branch master
  nothing to commit, working tree clean

The file that has just been modified is restored to the state before the modification;

git checkout command can also add the -- parameter, which means that README.txt file in the work area are undone. There are two cases here:

• One is that README.txt has not been placed in the temporary storage area since the modification. Now, if the modification is undone, it will return to the same state as the version library;
• One is that README.txt was modified after being added to the temporary storage area. Now, if the modification is cancelled, it will return to the state after it was added to the temporary storage area;

In short, it is to return this file to the state of the git commit or git add

If the modified file has already performed the git add addition operation, but not yet commit we can also use git reset HEAD <file> to undo the file modification in the temporary storage area and restore it to the work area;

$ git reset HEAD README.txt

  Unstaged changes after reset:
  M       README.txt

git reset command can not only roll back the version, but also roll back the modification of the temporary storage area to the work area. When we use HEAD, it means the latest version; when we git status , we can see that the file is back to the git add before 061000a654acde ;

Summarize:

• 1. If you want to discard the modification of the workspace, use the git checkout -- file command;
• 2. The modified content is added to the cache area. If you want to discard the modification, you need to execute the command git reset HEAD <file> first, then go back to the operation step of 1., and then execute the git checkout -- file command;

Version rollback

In the section of viewing history above, we can see that when the git log command is executed, the log signature will have a long string of numbers and letters, similar to this f4c0417dd64876552e17ff63dcb76c2baa33feee ;

SVN , the logs (also called version number) submitted each time by SVN git is a very large number calculated by SHA1

In our daily work, if we accidentally submit the modified file to the remote warehouse, we can also use git to return the version to a previous version;

First, git must know which version is the current version, in git in with HEAD represents the current version, the previous version is HEAD^ , the previous version is HEAD^^ ... Beyond a plurality of N versions, write ^ relatively easy to count Come, you can directly use HEAD~n instead, where n refers to the specific value;

Now, if we want to return the current version to the previous version, we can use it directly:

$ git reset --hard HEAD

 HEAD is now at b560ce1 修改.md里面的文件内容

If there are a lot of versions recorded in our log, and the new version before the last rollback version is not found, if bash has not been closed at this time, we can still see the previous new version fortunately. No.; we can use the reset command to roll back to the previous new version;

$ git reset --hard f4c041

  HEAD is now at f4c0417 提交修改

--hard followed by the version number, you don't need to write all, you only need to enter the first few git of the version number, 061000a654ae33 will automatically find the complete version number;

However, the above rollback operation is when bash has not been closed, we can still find the previous operation through the operation record, but when we use the $ git reset --hard HEAD^ rollback version, if it is closed or closed, bash Computer, if you want to restore to the previous version, you must find the version number of the previous version;

Fortunately, git also provides us with a git reflog command to record every command:

$ git reflog
  f4c0417 (HEAD -> master, origin/master) HEAD@{0}: reset: moving to f4c041
  f4c0417 (HEAD -> master, origin/master) HEAD@{1}: reset: moving to HEAD
  f4c0417 (HEAD -> master, origin/master) HEAD@{2}: commit: 提交修改
  b560ce1 HEAD@{3}: commit: 修改.md里面的文件内容
  2872d97 HEAD@{4}: initial pull 

At this time, we can use the reset command to specify which version to roll back to;

Remote warehouse

In order to be able Git project, we need to know how to manage our own remote warehouse; Git is a distributed version control system, and the same Git warehouse can be distributed to different machines; later we can build our own to run Git Server;

However, at this stage, in order to learn to use git , we can first use the Github to obtain our remote warehouse. This chapter is also git associate our remote warehouse;

Github is also relatively simple, we only need to Github , you can use it for free;

Add remote warehouse

This chapter is a practical chapter that combines the previous basic git ; we will create a remote warehouse from 0;

First, find an empty directory on our disk, and then execute the following command:

$ mkdir GithubTest
$ cd GithubTest/
$ git init

At this time, we have created a git warehouse locally; then we open Github and log in;

After successfully logging in, you can see a + icon on the New repository , and the following form items will appear:

After the creation is complete, we can see that an empty warehouse is created, and 3 files are automatically created for us, .gitignore , LICENSE , README.md ;

If you don't do anything, this warehouse will default to the README.md file as the homepage; the .md file is the abbreviation markdown

(It is strongly recommended to use the marckdown grammar to write notes or blogs);

git above operations, we can copy the generated 061000a654b111 address, and switch to our local bash command line, enter the command in the command line:

$ git remote add origin https://github.com/Scorpio-nan/GithubTest.git

After the addition is complete, the name of the remote warehouse is origin , which is git , or it can be changed to something else;

Since Github is not an empty warehouse, we need to execute the git pull <name> [param] command first to pull the contents of the remote warehouse to the local;

$ git pull origin master

  remote: Enumerating objects: 5, done.
  remote: Counting objects: 100% (5/5), done.
  remote: Compressing objects: 100% (4/4), done.
  remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
  Unpacking objects: 100% (5/5), done.
  From https://github.com/Scorpio-nan/GithubTest
   * branch            master     -> FETCH_HEAD
   * [new branch]      master     -> origin/master

origin is our warehouse name, master represents the main line (main branch); ( git branch will be introduced in detail later)

After the execution is complete, we can see that there are a few more files under the previously created empty folder, and they are all marked as tracking files (the first version of the git mark on windows is a green √ icon);

Now, let's make some changes to the content of the file in README.md
README.md

#### 使用方法
````bash
$ git clone https://github.com/marmelab/react-admin.git

$ cd react-admin
$ npm install
$ npm start
````

Then execute the file operation command of git

$ git status
  ...

$ git add README.md
$ git commit -m "修改.md里面的文件内容"
  ...

$ git push origin master
  Enumerating objects: 5, done.
  Counting objects: 100% (5/5), done.
  Delta compression using up to 8 threads.
  Compressing objects: 100% (3/3), done.
  Writing objects: 100% (3/3), 439 bytes | 439.00 KiB/s, done.
  Total 3 (delta 1), reused 0 (delta 0)
  remote: Resolving deltas: 100% (1/1), completed with 1 local object.
  To https://github.com/Scorpio-nan/GithubTest.git
     2872d97..b560ce1  master -> master

After the execution is completed, we will push the modification made README.md git server; let Gitbub page to verify whether our submission is successful;

As you can see, the github of the GithubTest warehouse on 061000a654b23f have been updated;

Clone from remote warehouse

Almost cloning warehouse operations and creation of operation, however, do not create an empty warehouse in the local good, just need to Github created above address good copy down the warehouse, then bash enter the command in git clone can;

$ git clone https://github.com/Scorpio-nan/GithubTest.git
  
$ cd GithubTest
$ ls
  LICENSE  README.md

If there are multiple people assisting in the development, then everyone can clone a copy from a remote location;

View remote warehouse

If you want to view the configured remote warehouse server, you can run the git remote command;

$ git remote

  origin

origin is the default name given to the cloned warehouse by git

Of course, you can also specify the -v item, which will display the abbreviation and the corresponding URL saved by git that need to be read and written in the remote warehouse;

$ git remote -v

  origin  https://github.com/Scorpio-nan/GithubTest.git (fetch)
  origin  https://github.com/Scorpio-nan/GithubTest.git (push)

Pull from remote warehouse

To pull data from a remote warehouse, you can execute git fetch [remote-name] :

$ git fetch origin

fetch command will pull the data to the local warehouse, but it will not automatically merge or modify the current work; at this time, we can use the git pull command to automatically grab and then merge the remote branch to the current branch;

$ git pull

Usually, in a multi-person collaborative project, if the operation is improper, git pull ; and, an error message will be displayed in the command line;

error: Your local changes to the following files would be overwritten by merge;

This shows that the local file is inconsistent with the file on the remote warehouse, and the local file will be overwritten by the file on the server. At this time, we have two choices:

1. If you want to keep the code you just modified locally, and pull the code above git to the local (the code just modified locally will be cached)

$ git stash
$ git pull origin master
$ git stash pop

In this way, the code on the server is updated to the local, and the code that has just been modified locally is not overwritten, and then the local code can be updated to the server by add commit push

2. If you want to completely cover the local code, the code pulled down on the server shall prevail, then we can directly go back to the previous version and then pull

$ git reset --hard
$ git pull origin master

Git alias

Git does not automatically infer the command you want when you enter some commands. If you don't want to enter the complete Git command every time, you can easily set an alias for each command git config

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

This means that when you want to enter git commit , you only need to enter git ci

Git branch

git branch is to store the modification record process separately, so that the separated branch is not affected by other branches, so multiple different versions of the modification can be made at the same time in the same warehouse;

Imagine that if we have a new requirement at work, we will directly add the required business code to the code, but if a small version of the project that is already online needs to be launched urgently at this time to solve the bug in the program;

At this time, it is cheating, because the local code has already added the requirements for the new version in the future. It is possible that this requirement needs to be online with the background api to be used normally. If you want to use the code before the new requirement, you can only change the version. Rolling back to before adding requirements, this also means that the subsequent work is useless; of course, you can also back up the existing code and synchronize it after restoring, but this will be very inefficient and more error-prone;

Branching can help us better manage different versions of the code;

Create and merge branches

git performing git init when, in fact, equivalent to automatically created for us a master branch; use git branch can see our current branch is located; git branch lists all our branches, ahead of the current branch will show *

$ git branch
 
* master

Assuming that master stores the code of the product that we have officially operated online, we will create a dev development environment code for master

$ git checkout -b dev

  Switched to a new branch 'dev'

The above git checkout -b command is equivalent to the following two commands:

$ git branch dev
$ git checkout dev

  Switched to branch 'dev'

We master created following a dev branch, and also for us to automatically switch to the dev branch, let us once again git branch look;

$ git branch

* dev
  master

Then, we can dev branch, for example, add some content to the README.md

$ git add *
$ git commit -m "这是我们在dev分支上做出的修改;"

  [dev 4fee0ed] 这是我们在dev分支上做出的修改;
   1 file changed, 19 insertions(+)

Now that our work on the dev branch has been completed, let's switch to the master branch;

$ git checkout master

  Switched to branch 'master'

$ git branch
  dev
* master

After switching to the master branch, after checking the README.txt file, I found that the content we just added is missing, because the modification just now was made on the dev branch, and master branch has not changed at the moment;

This is git branch. Corresponding to the development work, dev is used for our development needs, and master is the version currently running online;

Now, we need to dev the changes made on the master branch to the 061000a654b5e0 branch; we can use the git merge command:

$ git merge dev

  Updating f4c0417..4fee0ed
  Fast-forward
   README.md | 19 +++++++++++++++++++
   1 file changed, 19 insertions(+)

git merge <branch> command is used to merge the specified branch into the current branch; after merging, we will check README.md , and we can see that the content on the dev branch is exactly the same;

He noted the above Fast-forward information, Git tells us that this merger is fast forward mode, that is, directly to the master point dev currently committed, so the merger is very fast;

After the merger is completed, the dev branch can be deleted;

$ git branch -d dev

  Deleted branch dev (was 4fee0ed).

$ git branch
* master

Merge conflict

Merging branches is often not as simple as the above-mentioned quick merge; for example: on the dev branch, we have made many changes to the development version; but at this time, we also need to make some changes in the master master and dev branches respectively There are new submissions;

In this case, git cannot perform fast merge. You can only try to merge the modified versions, but this merge often has conflicts;

$ git merge dev

  Auto-merging README.md
  CONFLICT (content): Merge conflict in README.md
  Automatic merge failed; fix conflicts and then commit the result.

git tells us README.md file, and we must manually resolve the conflict before submitting; we can use the git status command at any time after the merge conflict to view the files that are in the unmerged unmerged

$ git status

  On branch master
  You have unmerged paths.
    (fix conflicts and run "git commit")
    (use "git merge --abort" to abort the merge)

  Unmerged paths:
    (use "git add <file>..." to mark resolution)
          both modified:   README.md
  no changes added to commit (use "git add" and/or "git commit -a")

Any conflicting files that need to be resolved will be marked as git . 061000a654b722 will add conflict markers to conflicting files, and conflicting files will contain some special sections:

<<<<<<< HEAD
随便改一改东西
=======
这是在 dev 分支上做出的修改


>>>>>>> dev

The version indicated by HEAD master branch is located) is in the upper half of this section (the part above ======= ), and the version indicated by the dev ======= . In order to resolve the conflict, we You must choose ======= of the two parts divided by 061000a654b750; or we can merge these conflicts by ourselves and delete some half of the content;

Or we can use git merge --abort to undo this merge; after manually resolving these conflicts, use the git add command on each file to mark it as conflict resolved;

Force push to remote

$ git push -u origin master -f

Branch development process

In actual development, we should manage branches according to several basic principles:

• 1. First of all, the master branch is very stable, that is, it is only used to release the version and cannot be developed on it;
• 2. dev branch is unstable. It is used to iterate the new version. After the development is completed, it will be merged into the master branch;
• 3. In the development of multi-person collaborative projects, everyone develops on the dev branch, and everyone has their own branch, and often merge on the master

Remote branch

Remote reference is a reference to a remote repository, including branches and labels; we can git ls-remote view a complete list of references to remote displays; or by git remote show more information to gain remote branches;

Our company's automated operation and maintenance architecture is based on the git branch to manage the site code; the collaboration process is probably for developers to develop a new version, submit the business code of different sites to the git , and then the server according to different To pull the code on the branch and push it to the server;

Git quickly clones large projects

As the company’s business lines increase and products become more and more, a single git warehouse can no longer meet business needs. We have to use multiple warehouses to manage projects; and, while multiple projects are iterating, we also need to use Multiple branches to do version control;

With the increase in business volume, some projects have become very large. If we just want to get the code of the project and subsequent updates, we don't need to pay attention to the historical submission records of the project, then we only need to clone one The last commit of the branch;

• Select to clone a single branch: git clone --branch <branch_name> <remote-address>
• Clone only the latest commit record: git clone <remote-address> --depth 1
• Combination: git clone --branch <branch_name> <remote-address> --depth 1

-- depth represents the depth of the clone, --depth 1 represents only the latest submission record and the latest content after this submission, without cloning the historical submission, the impact is that the historical submission record cannot be viewed, but the cloning speed is greatly improved;

$ git clone --branch=dev http://git.nbet-group.com dev --depth=1

git clone command, url , the cloned folder name is the name added by the command line, if not, the folder will be named after the cloned project name;

Git forcibly overwrite local code

Git forced overwrite:

git fetch --all                     #  拉取所有更新，不同步
git reset --hard origin/master      #  本地代码同步线上最新版本(会覆盖本地所有与远程仓库上同名的文件)
git pull                            #  更新一次（其实也可以不用，第二步命令做过了其实）

git forcibly overwrites local commands (single execution):

git fetch --all && git reset --hard origin/master && git pull

Git cancels all local modifications

Many files have been modified locally, and some of them are newly added because they are not needed for development and want to be discarded, or because a certain function is implemented, but it is not successful, but the code is messed up. At this time, we You can cancel all local changes and return to the state before the change. You can use the following command:

git checkout . #本地所有修改的。没有的提交的，都返回到原来的状态
git stash #把所有没有提交的修改暂存到stash里面。可用git stash pop回复。
git reset --hard HASH #返回到某个节点，不保留修改。
git reset --soft HASH #返回到某个节点。保留修改
 
git clean -df #返回到某个节点
git clean 参数
    # -n 显示 将要 删除的 文件 和  目录
    # -f 删除 文件
    # -df 删除 文件 和 目录

Single execution:

git checkout . && git clean -xdf