Table of Contents
Git initialization
Git installation
Git basic operations
Create a git local repository
Configure git
workspace, staging area, version library
Add files, submit files
View .git files
Modify files
Version rollback
summary
Git initial
Git is a very powerful version control tool. It can quickly version manage our documents and codes.
Let’s look at the following example to understand why version control is needed.
In work or study, we may often encounter such a scenario. For example, when we need to provide a piece of information to a leader, we first write a version and give it to the leader, but the leader is not satisfied after reading it and asks him to re- So we wrote a second version, but the leader was still not satisfied, so he wrote a third version. After reading it, the leader said it was not as good as the second version of the document, so he asked for the second version of the document.
In this case, it will be more troublesome if we want to restore the second version of the document.
But if we hand over the document to git for management, that problem will no longer be a problem.
Git is a tool that is very frequently used, whether in the enterprise or in learning. In the enterprise, we need to cooperate in developing projects, so git is an indispensable tool to complete the project together.
Git installation
If you want to do your job well, you must first sharpen your tools. Next, let’s install git first.
We installed the git environment on CentOs.
Subsequent operations are also performed on CentOS.
Since there is no git on our system, we need to install git.
Before git is installed, after we enter git on the console, this scenario will appear:
git -bash: git: command not found
In the above situation, the system prompts us that git is not installed.
In fact, installing git on Linux is very simple, and only requires one command:
yum -y install git
After operating this command, we can enter git –version in the console to view the version we installed.
So far, our git installation has been completed. It can be seen that the installation of git is very simple, and it can be said to be a fool-proof installation.
Git basic operations
Next we will introduce some basic operations of git. These basic operations are generally used most frequently.
Create git local warehouse
The command in the above picture is to create a new git repository locally.
The git init command is the command to create a local warehouse.
After we created it, we found a .git hidden directory in the current warehouse. This directory is used to manage everything under this warehouse.
The following is everything in the .git directory.
We will introduce the contents in this .git directory in detail later.
Configure git
Next, you need to configure git. This configuration is very important. It mainly configures the user name and email address. This configuration is used to distinguish which user made the submission.
Configuration command:
git config user.name "Your Name" git config user.email "[email protected]"
You need to replace user.name and user.email with your own.
You can use git config -l to view 
–global is optional. If this option is enabled, all Git repositories on this machine will use this configuration. If you want to use different names or e-mails in different repositories, you do not need the –global option, but please note that you must be in the repository when executing the command.
Delete the corresponding configuration command:
git config --unset user.name git config --unset user.email
If you need to delete the global configuration, just set the –global option.
Workspace, temporary storage area, version library
Workspace: The workspace is where code and documents are written under the git repository.
Temporary storage area: called stage or index in English. It is generally stored in the index file (.git/index) recorded in .git. We sometimes call the temporary storage area the index (index).
Version library: name warehouse, English name repository. There is a hidden directory .git in the working area. It is not counted as the working area, but is the Git repository. All files in this repository can be managed by Git. Git can track the modification and deletion of each file, so that the history can be tracked at any time, or it can be “restored” at some point in the future.
The left side of the picture is the work area, and the right side is the version library.
Git’s repository stores many things, the most important of which is the temporary storage area.
When creating a Git repository, Git will automatically create a unique master branch for us, and a pointer to the master called HEAD. (Let’s discuss the concept of HEAD and HEAD later)
When the git add command is executed on a file that is modified (or added) in the working area, the file index of the directory tree in the staging area will be updated.
When the commit operation git commit is executed, the master branch will be updated accordingly, which can be simply understood as the directory tree in the temporary storage area will be actually written to the repository.
From the above description, we can know that files entered by creating or pasting cannot be called new files in the warehouse, but only new files in the work area. You must use the git add and git commit commands to add files to the warehouse for management! ! !
Add file, submit file
We create a new file under the directory containing .git. We can use the git add command to add the files in the workspace to the staging area.
- Add one or more files to the staging area git add [file1] [file2] …
- Add a directory to the staging area git add [dir]
- Add the changed files in the current directory to the temporary storage area git add
Then use the git commit command to submit the files in the staging area to the local warehouse.
- Submit all the contents of the staging area to the local warehouse: git commit -m “message”
- Submit the specified files in the temporary storage area to the warehouse area: git commit [file1] [file2] … -m “message”
Note: The git commit -m option must be followed by the description information of this submission. This is indispensable. It is used to record the details of your submission, and it must be described well.
[root@VM-8-9-centos TestGit]# git init Initialize an empty Git repository at /root/TestGit/.git/ [root@VM-8-9-centos TestGit]# ls -a . .. .git [root@VM-8-9-centos TestGit]# touch 1.txt [root@VM-8-9-centos TestGit]# touch 2.txt 3.txt [root@VM-8-9-centos TestGit]# ls 1.txt 2.txt 3.txt [root@VM-8-9-centos TestGit]# git add 1.txt [root@VM-8-9-centos TestGit]# git add 2.txt 3.txt [root@VM-8-9-centos TestGit]# git commit 1.txt -m "Submit a file" [master (root commit) da0d6e8] commits a file 1 file changed, 0 insertions( + ), 0 deletions(-) createmode 100644 1.txt [root@VM-8-9-centos TestGit]# git commit -m "Commit all files in the staging area" [master 890a29d] Submit all files in the staging area 2 files changed, 0 insertions( + ), 0 deletions(-) createmode 100644 2.txt createmode 100644 3.txt [root@VM-8-9-centos TestGit]# ^C [root@VM-8-9-centos TestGit]#
At this time We can use the git log command to view commit records:
This command displays logs from in to far.
If you feel that the output information is too much and dazzling, you can try adding the –pretty=oneline parameter:
We found that there are some numbers on it, such as 890a29………….. This number is the commit Id (version number) we submit each time. The commit id of git is A series of calculated hexadecimal numbers.
To understand the meaning of these numbers, you need to enter the .git directory.
View .git file
- Index is the temporary storage area. The files and codes we add are all in this directory.
- HEAD is the pointer to the master branch that we point to by default.
In fact, the so-called master branch is: 
You can see that the master branch printed a string of numbers. In fact, this number is the commit id we submitted recently.
We can see it by printing the log:
[root@VM-8-9-centos TestGit]# git log --pretty=oneline 890a29d9bdb4b08ce1a6c62cb2f9686ca9c0e451 Submit all files in the temporary storage area da0d6e8dbbda2503b782b862bb1d332dc2a6a5a1 Submit a file [root@VM-8-9-centos TestGit]#
You can see that it is completely consistent. In other words, we are now submitting the document to the master branch.
- objects is the object library of Git, which contains various repository objects and contents created.
When the git add command is executed, the directory tree in the temporary storage area is updated, and at the same time, the modified (or newly added) file content in the working area is written to a new object in the object library, located at \ “.git/objects” Recorded, let’s see what these objects do.
We found that there are many directories in it. When searching for object, we need to divide the commit id into 2 parts. The first 2 digits are the folder name, and the last 38 digits are the file name.
After finding this file, you generally cannot directly see what it is. This type of file is a file encrypted by SHA (Secure Hash Algorithm). Fortunately, we can use the git cat-file command to view the version. Contents of the library object:
All our operations on the local warehouse directory will be recorded by git, that is, in the objects directory, where all operations on the local warehouse are recorded.
Modify file
Git is better designed than other version control systems because Git tracks and manages changes and files.
What is a modification? If you add a new ?, this is a modification. Deleting a is also a modification. Changing some characters is also a modification. Deleting something or adding something is also a modification. , even creating a new file is considered a modification.
We can modify the file we submitted earlier,
We use vim 1.txt to open the file, write hello world in it, and then save and exit.
At this time, the 1.txt file in the warehouse is different from the 1.txt file in our workspace. We can use the git status command to check whether there have been any changes since your last submission. Modify again
The above results have told us that 1.txt has been modified, but has not been added or submitted yet.
At this point we know that file 1.txt has been modified, but we don’t know what content has been modified. We can use the command:
git diff 1.txt to see what has been modified.
Here we can see that we added a line hello world.
When we know what content we have modified, we can add and submit.
When we check again after adding, we will find that it will prompt you which change you want to submit. Then we can submit it.
Version Rollback
We have also mentioned before that Git can manage historical versions of files, which is also an important function of the version controller. If one day you find that there are many problems with the previous work and you need to restart at a specific historical version, at this time, you need the version rollback function.
To execute the git reset command to roll back the version, you can specify the version submitted for a certain time to be rolled back.
To explain, the essence of “rollback” is to rollback the content in the repository. Whether to rollback the working area or the temporary storage area is determined by the command parameters:
The syntax format of the git reset command is: git reset [–soft | –mixed | –hard] [HEAD]
- –mixed is the default option and can be used without this parameter. This parameter will return the contents of the temporary storage area to the specified submission version content, and the work area files will remain unchanged.
- The –soft parameter does not change the contents of the working area and the staging area, but only rolls back the version library to a specified version.
- The –hard parameter will return both the staging area and the working area to the specified version. Remember not to issue this command when there is uncommitted code in the workspace, because the workspace will be rolled back and the code you have not submitted will never be retrieved, so be careful before using this parameter.
- HEAD Description:
It can be written directly as commit id to specify the returned version.
HEAD table? Current version
HEAD^ Previous version
HEAD^^ Previous version
And so on…
You can use a digital table:
HEAD~0 table? current version
HEAD~1 Previous version
HEAD^2 Previous version
And so on…
In order to facilitate testing, we modified the 1.txt file three times, adding and submitting it.
First time:
the second time:
the third time:
View historical commit records:
Now, If we find an error in version 3 after submitting version 3, we want to roll back to version 2 and start writing based on version 2 again. Since what we want here is to roll back the contents of the workspace to version 2, we need to enter the –hard parameter, for example:
Our rollback here is based on the commit ID directly.
Now we find that the 1.txt file in the workspace has been rolled back to version 2. We also find that the head has pointed to version 2.
It is worth mentioning that Git’s version rollback speed is very fast, because Git has an internal HEAD pointer pointing to the current branch (here is the master), and the refs/heads/master file saves the latest version of the current master branch. commit id. When we roll back a version, Git only stores a specific version in refs/heads/master, which can be simply understood as the following intention:
Summary
This article is the basics of git. We will continue to update other operations and advanced features of git in the future.