directory

• Write it first

• View warehouse status (Status, DIFF)

• Version rollback

•Git workspace description

The next step,

• Write it first

In the previous article, you have roughly completed the basic repository creation and file submission. Now let’s move on from the work we did in the previous article (submitting a readme.txt file). If you don’t know, check out the previous article’s Git series: How to create and initialize repositories and add updates.

• View warehouse status (Status, DIFF)

We have submitted a readme.txt text to the warehouse, and then modify the text to change the contents (just type a paragraph of text), and then we can use the following command to view the current status of the warehouse.

$ git status
# this command can view a state of the current warehouse, but this command will only tell you fuck
# What files have been made will not tell you exactly what changes have been made
You can use the command below to view the details

$ git diff
This command can be used to view the details of the operation
Copy the code

• Version rollback

After committing the previous changes using add and commit directives, you have committed two versions so far, so you can try several more changes and commit and review the instructions. Think about it, once or twice is fine, but if you commit a lot of versions, will you be able to remember how many times and when you committed? Git is already ready for you, and you can use the following command to view it. In the output below, the large string followed by commit is the COMMIT ID (version number). How is this generated? It is a very large number calculated by SHA1 and expressed in hexadecimal notation, which has the advantage of avoiding version number conflicts in multi-party collaborations.

View the warehouse commit log, including the committer, time, and related files, in order of output from near to far
$ git log 
If you want to see the version number of the timeline, you can add the following parameter to the end
$ git log --pretty=oneline
Copy the code

 

Now that we know the timeline and version of the commit log, we are trying to fall back to the version we want, with the following instructions

Git Git Git Git Git Git Git Git$git reset --hard HEAD^ $git reset --hard HEAD^# indicates the previous version
$ git reset --hard HEAD^^  # indicates the previous version
$ git reset --hard HEAD~100  # represents the first 100 versions
Copy the code

After reverting to the previous version, we can use the cat command to look at the contents of readme. TXT to see if it has reverted. After checking, you will find that the current version has been rolled back.

$ cat README.txt # View the contents of the readme.txt text
Copy the code

Note that at this point you can execute the git log command again to view the historical version of the current timeline, as shown in the image below. You will notice that the latest version is missing. Very panic, how to do? Git will use the commit ID to find the only version of Git, as long as the original command line is still open. Git will use the commit ID to find the only version of Git. The instructions and related operations are shown below. The version number (my future is: 23 dd7cc45ab3098897fdd4a54d123e9569a1e1c9, pay attention to oh, you don’t like me).

$git reset --hard version numberCopy the code

 

Git is so convenient that the fallback can be interpreted as an array or pointer (actually a pointer) that you can find as long as you have the corresponding index or address. As mentioned earlier, you searched for the version number without closing the Git window, so you can easily find the version number, but what if you closed the Git window and didn’t save the relevant version number? Don’t worry, you can use the following command to query the warehouse for every operation command.

$ git reglog  This command queries the historical operation instructions of the warehouse
Copy the code

•Git workspace description

Here I refer to the official documentation of Git (specific address here), which is in English. I will give a brief explanation and add some popular understanding. Git is divided into working trees, staging areas, and Git directories.

The working tree is a single extraction of a version of the project, and these files will be pulled from the compressed database in the Git directory, putting that on disk for developers to use or modify. A staging area is a file, usually contained in a developer's Git directory, that stores information about the next commit. The technical term is "index". The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, which is what you copy when you clone a repository from a computer. The basic Git workflow is as follows: 1. Modify files in the work tree. 2. Optionally, you can temporarily store changes that you want to be part of the next commit, which only adds those changes to the staging area. 3. Perform a commit that retrieves the files as they are in the staging area and stores the snapshot permanently in your Git directory. If a particular version of a file is in a Git directory, it is considered committed. If it has been modified and added to a temporary zone. If it has not been changed before it was checked out, it will be modified.Copy the code

It can be simply understood as workspace and staging area. Staging area includes staging area and the master branch that Git helped me to create automatically. The workspace is the project directory for our project, which is in my Gittest directory. The staging area is in a hidden.git file. The general workflow is that you make changes in the project directory of the workspace, commit to stage, and historically all operation branches of the repository are added to master.

The next step,

So far, I’ve covered some of Git’s rollback procedures and instructions. Next, I’ll cover changes and deletes.