Make writing a habit together! This is the fifth day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.

The previous article covered some basic operations on local libraries, such as initialization, add, commit, and so on. This article will show you how to switch project versions using Git.

View submission History

Before making a version switch, we need to know one directive:

git log
Copy the code

This command can view the submission history, execute this command, the result is as follows:We have made two commits before, and this directive shows both of them, including the author identity of the submission, the submission time, the submission description, etc. If you look closely, you will notice that the two submitted information presentations are not quite the same:The first is that the string after the commit is different, which is a value calculated by a series of hash algorithms as the index for each commit. Secondly, in the second submission, there is this message:(HEAD -> master)The HEAD pointer is actually a pointer to the current version, so to switch the version, we need to change the point of the HEAD pointer.

For further testing, I’ll make one more change here and commit:

View additional instructions for commit history

The git log command can display the commit history, but sometimes it is not convenient to display too much detail. When the number of commits increases gradually, this will obviously increase the burden of finding some important information. Therefore, we need to master several commands about viewing the commit history.

Such as:

git log --pretty=oneline
Copy the code

Print the commit history as a single line, with the following result:You can also use:

git log --oneline
Copy the code

Running results:The content displayed in this way will be more concise, with only partial hash values displayed.

One last instruction:

git reflog
Copy the code

Running results:The difference between displaying the commit history in this way is that it has one more piece of information:HEAD@{0}.

For example, HEAD@{1} in the second submission means that the HEAD pointer needs to be moved once to switch from the current version to the second submission. Similarly, HEAD@{2} means that switching to this version requires moving the HEAD pointer twice.

Only git reflog can display the commit history of all versions.

Let’s say you have a project that has been committed many times and you want to go back to the previous version. When you go back, other commands to look at the commit history will not see the history prior to the current version. Git reflog does.

How do I switch the version

After the foreshadowing in front, I believe that we have a general understanding of the implementation of version switch, the next is to master the specific instructions. Git provides three ways to switch versions:

  1. Based on index
  2. Use ^ operator
  3. With ~

Switch the version based on the index value

This is a convenient way to switch versions, since it is based on the index value, we need to get the index value first, execute the command:

git reflog
Copy the code

If I want to switch to the version I submitted the first time, execute the command:

git reset --hard 43dc5b0
Copy the code

Running results:The HEAD pointer is currently in 43DC5B0, and the version switchover is successful.

It is not necessary to write out all the hash values when switching versions, but only the part that uniquely identifies the current version.

Now go to the test. TXT file in your workspace and open it:The file is empty, indicating that the version has been rolled back to its original state.

The command can not only be retracted, it can also be moved forward, for example, if I want to move forward to the version I committed the second time and execute the command:

git reset --hard 47ee58a
Copy the code

Running results:Take a look at the test.txt file again:That’s right, the second submission is this.

In summary, with the index value, we can switch to any version.

Version switch based on ^ symbol

This symbol can also switch versions, but it can only go backwards, not forward. Let’s first switch to the latest version with the index value and execute the command:

git reset --hard 05f2f17
Copy the code

Then execute the command:

git reset --hard HEAD^
Copy the code

Running results:When the version is rolled back to the second commit, check the contents of the test.txt file:The directive contains several^The symbol represents a rollback of several versions.

Switch the version based on the ~ symbol

It is possible to switch versions using the ^ symbol, but if I want to go back to dozens of versions, the instruction would have to be followed by dozens of ^ symbols, which is obviously not a good choice, so I can use the ~ symbol instead.

Let’s say I need to roll back fifteen versions, and I can do the following:

git reset --hard HEAD~15
Copy the code

The number after the ~ symbol indicates the number of versions to be rolled back. Therefore, this method can only roll back the version, but cannot advance the version.

The parameters of the reset command are described

Git reset git reset git reset Does it have any other parameters?

Here are the three parameters of the reset command:

  1. soft
  2. mixed
  3. head

Let’s look at soft first. Here’s how the official documentation explains it:

Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files “Changes to be committed”, as git status would put it.

This means simply moving the HEAD pointer in the local library does not touch the index file or working tree at all.

Then look at mixed:

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

This moves the HEAD pointer in the local library and resets the index, but does not reset the working tree.

And finally, head:

Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

This moves the HEAD pointer in the local library and resets the index and working tree.

Soft parameter

For example, I am currently in the second committed version and execute the following command:

git reset --soft 05f2f17
Copy the code

We use this command to switch to the latest version, view the commit history, and execute the command:

gt reflog
Copy the code

Running results:Currently the HEAD pointer does point to the latest version, but let’s look at the test.txt file:Test.txt is not restored to the latest version of the file, and we can check the status by executing the following command:

git status
Copy the code

Git status: > < span style = “font-size: 10.5pt;” Why is that?

Note that the files in the workspace were not actually modified, but because the HEAD pointer to the version area was changed, the contents of the staging area did not correspond to the version area, so the contents of the staging area were modified. That is, the version of the version area goes back, which is equivalent to the contents of the staging area going forward, which is why the terminal will tell us that a file has been modified. In fact, it is not really modified, so it may be a little round.

Mixed parameter

Now our version is in the latest version, let’s use the mixed parameter to go back to the original version and try:

git reset --mixed 43dc5b0
Copy the code

Running results:After successfully backing back to the original version, let’s look at the test.txt file:Git status:Here it’s red again, red means it’s not tracked by the staging area. How do you understand that?

In the same way, the mixed parameter changes the pointer to the version area and resets the index, so the local library and the staging area are in the same version, and they both fall back. In this case, the workspace version is relatively forward, not really, but relatively.

Hard parameters

This parameter causes the versions of the version area, staging area, and workspace to change at the same time, so there is no previous problem.