Because it combines scenarios that you might encounter in development, it’s a long time, but I think it’s very helpful for you to understand how git works, rather than memorizing commands.
The HEAD pointer always points to the latest version number of the current branch, HEAD ^, HEAD ^, the number of ^ n or HEAD ~ n, n represents the previous n version numbers.
Using Linux RM directly in a project only deletes the files in the workspace. Git RM deletes the files in the stage at the same time as deleting the files in the workspace, or uses git RM — cache to delete only the files in the stage.
Some basic operations
# Global configuration git config --global user.name "your username" git config --global user.email [email protected] git config --global color.ui true # mkdir git_proj & cd git_proj git init echo "# readme.md" >> README.md git add README.md git commit -m "readme commit" # Add remote warehouse and give it an individual name origin git remote add origin [email protected]:username/repositoryName.git # Push the local warehouse to the master branch of origin and associate with it (- u's role, not later used) git push -u origin master # Get the latest source code from the master branch of the remote warehouse origin and download it to the TMP branch git fetch origin master:tmp # What changes have been made to the TMP branch versus the master branch git diff master tmp # merge TMP branches to master branches git merge tmp # Clone copy A complete remote warehouse to local git clone [email protected]:username/repositoryName.git # pull gets the master branch of origin and merges directly with the current branch # So there may be conflicts. git pull origin master
The checkout command has two main functions: switching branches and rolling back files to the current stage version or repository version
1. Switching Branch
# Switch to the new_branch branch git checkout new_branch # Create and switch to the new_branch branch git checkout -b new_branch
2. Roll back the workspace file to the latest stage version or repository version, that is, check out the latest version from stage or repository
# - is the parameter after the name of the file identifier table to avoid the ambiguity of switching branch for the file git checkout -- <filename>
When you roll back, you first check whether there is a corresponding file in the stage, and if not, you will use the latest version of repository. After several modifications and adds to a file, we can only roll back the file to the latest version of add using checkout.
But in some scenarios, we might want to roll back to the latest version of repository. What do we do? It’s easy to do with the reset command.
Give the command first:
git reset HEAD <filename> & git checkout -- <filename>
This allows you to roll back the filename of the workspace to the latest version in repository. Specific principles will be explained in detail in the examples.
The reset command of Git is rather roundabout and requires patient understanding. Simply put, reset has three reset levels, and we need to understand exactly what each level does.
Soft: Return version number. Acting on repository
Mixed: Return version number and reset stage. Acting on repository and stage
Hard: Return version number, reset stage, reset workspace source. Acting on repository, stage and workspace
Let’s briefly show the version number of repository, and try three levels of reset for demo.
git log Version D (HEAD) <--HEAD pointer version C (HEAD^) version B (HEAD^^) version A (HEAD~3)
git reset [--soft|--mixed|--hard] version_no <filename>
Soft: Simply move the repository HEAD pointer to the version number. There is no change in stage and workspace.
# Roll back the HEAD pointer to the previous version and use git log. You will find that the submission log is back to the previous version number. git reset --soft HEAD^ # Current status of version number Version C < -- HEAD pointer version B version A
–mixed：默认选项，移动 repository 的 HEAD指针 到指定版本号，同时用此版本重置 stage 区，所以可能会让工作区的某些文件处于 unstage 状态（当工作区的文件与 repository 中的版本不一致时）。 Note that you can specify files here. Soft itself has nothing to do with the file, but hard cannot specify the file separately and can only reset it all.
# HEAD Pointer or Point to HEAD git reset HEAD^2 <filename> # Current status of version number Version B < -- HEAD pointer version A
The HEAD pointer points to version B, and the stage has been reset by the version B file, and the workspace is unaffected.
Here’s a practical tip:
git reset version_no <filename> & git checkout -- <filename>
Together, these two commands allow the specified file in the workspace to be rolled back to the corresponding version_no version in repository.
If version_no is HEAD, you can roll back the file to the latest submission.
Hard: Use cautiously!!! Move the repository’s HEAD pointer to the specified version number, and use this version to reset the stage area and workspace source code. Special attention should be paid here to the fact that the source code of the workspace will also be overwritten and reset, and all your modifications will be lost. Simply put, the code is completely restored to the specified version. Hard cannot specify a file, either rollback or full rollback.
# HEAD Pointer or Point to HEAD git reset --hard HEAD^3 # Current status of version number Version A < -- HEAD pointer
At this point, the HEAD pointer points to version A, and the stage and workspace files have been reset by version A files. The state of the project is completely back to the moment you press the Enter key when you submit version A.
Git RM is different from using RM directly. Git RM deletes the contents of workspace and stage area. Note: You can’t use it here anymore.
git checkout -- <filename> Roll back and forth, because there is no filename file in the workspace, and there is no way to associate with repository. You can only use git reset HEAD < filename > to reset this file in stage, and then
git checkout -- <filename>
git rm [--cached] [-r] [-f] <filename>
Here’s a hint, just want to delete the files in stage and make the files out of GIT management, you can use it
git rm --cached <filename>
At this time, the filename of the workspace will not be deleted, but the status will be changed to untracked, and the stage will record the status of the filename to be deleted. If submitted, the version library will add a deleted version of the filename.
There is a difference between deleting files in stages and reset commands to reset files in stages. Deleting changes file status to untracked, while resetting changes file status to unstage (if the workspace and stage file content are inconsistent).
Small instance scenarios:
1. Roll back a file in the workspace to the specified repository version
In our work, we may modify and add to stage several times for a file, and then find that the idea is completely wrong and need to be redesigned and developed.
For example, after I submitted version A of the file foo, I modified version B and C twice and added it to the stage area. After the third revision, I found that the original idea was wrong and needed to be redesigned. Then use it directly
git checkout -- foo You can’t get the original version A because the stage area also stores the C version of foo. At this point, we can use it.
git reset HEAD foo Command, the latest version of repository contains version A of foo. The command will use version A of foo to reset the stage area without moving HEAD. The foo file in the stage area after the command is executed is version A. Let’s reuse it.
git checkout -- fooThe foo D version of the workspace can be rolled back to version A. Namely:
git reset HEAD foo & git checkout -- foo
HEAD stands for the current version, so the HEAD pointer will not move. At the same time, the stage area will be reset by the current version of filename of the repository, which means that the filename stored in the stage area is the same as that in the repository. At this point, we will use it again.
git checkout -- <filename> You can roll back the filename of the workspace to the current version of repository. In fact, reset — mixed resets the stage area, and checkout checks out the files in the stage area to the working directory. Of course, reset is flexible enough to roll back any given version.
In fact, if you just roll back to the current version, there is another command that can achieve the same function.
git rm --cached <filename> & git checkout -- <filename>
git rm --cached <filename>The file in stage will be deleted, the state of the file will be changed to untracked, and then checkout will find the file in stage wood, so the file will be checked out in the current version of repository.
- Git diff – < filename > workspace comparison temporary area
- Git diff — cached – < filename > temporary comparisons of current versions of local libraries
- Git diff HEAD~N – < filename > workspace compares the Nth version of the local library
- Git diff HEAD HEAD ^ – < filename > HEAD comparison HEAD^
- Git diff master TMP – < filename > Master comparison TMP
- Git diff SHA1 SHA2 – < filename > Compare the differences between the two historical versions
Above is the whole content of this article. I hope that the content of this article has a certain reference value for everyone’s study or work. If you have any questions, you can leave a message and exchange it. Thank you for your support to developpaer.