We use any version of the management tool, the reason is that we want to record file additions, modifications, deletions and other related operations, when we modify the file error, you can promptly return to the "backup" file without error. Of course, git as a good version of the management tools such a function is certainly not less, let's look at some version management related commands.
command: Git log
Git log can record our git commit operation (does not log git add operation, if you have not done a git commit, then git log will not show anything), each git commit will produce a record, Each record represents a commit, and a record consists of four parts.
commit: is a very large number computed by SHA1, in hexadecimal notation, is the unique identifier of this operation (the value is not duplicated each time the commit), we can find the exact commit operation, to restore to this version to lay a solid foundation.
Author: Author of this release and the author's mailbox
In multi-person collaboration, everyone has the possibility to make some adjustments to the file, how to distinguish who made these adjustments, which is used in the author. We can use git config user.name and git config user.email to get the current user name and user mailbox, if not set or need to be adjusted, can be--global user.name "new name" via git config To make adjustments. Setting up author is necessary, and it is best to set it up immediately after git init so that you can record the author information you set when you make Git commit.
Date: Day of submission.
finally : The last line is the description of this submission, that is, our git commit-m content, which allows us to understand why this commit operation, for the future version of the recovery to lay a solid foundation.
Using git log directly will show detailed information about each commit, but when the commit information is too high, or if we don't want such detailed information, then we can use git log for another usage.
git log--pretty=oneline
There is a certain, so that a screen can show more commit information. command: Git reset git log just helps us to record each commit operation, we want to make a different version switch, also need to use the git reset command. Before we do this, we'll do a few more commits. The preparation is ready, let's get started.
method One:
git reset--hard head^
Git reset is the version fallback command,--hard is a parameter of the fallback command, temporarily do not delve into what it means, just remember that this operation can achieve the purpose of our fallback. In the previous section we'll consider it as a fixed format for implementing version fallback, and we'll focus on head^. In Git, head represents the current version, in the example above is "add four line", and add a ^, the current version of the previous version, is the example of "Add third line", each plus a ^ represents a more previous version, such as head^^ said " Add second line "This version, if you want to go back to 100 versions before, need 100 ^, of course, the fallback version is too front, the light write ^ is also a problem, and Git provides another way to solve the problem.
Method Two:
git reset--hard head~1
The head^ replaced with a head~1, of which 1 represents back several versions, if you need to fall back to 10 before the version, just need to change the head~1 to Head~10, is not more than 10 ^ convenient a lot of it. It seems convenient, but there are still shortcomings, if you want to fall back to a version of the time, it is not necessary to check the difference between this version and the current version. Git also takes this into account, so it provides a third way for us to use it.
Method Three:
git reset--hard 1e7fac4
Remember the commit that was mentioned in git log just now, when we changed head to commit. It is because of the uniqueness of the commit string that we can quickly and accurately fall back to the version we need, without needing to find the difference between the current version and the switch version. About the--hard behind the string, I believe many friends still have doubts, the following small series on one answer.
question one: where the string comes from. Git will generate such a string every time git commits, so you can use git log to see each version of the specific commit string value.
question two: How to fill in the string when the version fallback. In fact, this does not have a rigid rule, after a small series of tests, the string is at least 4, that is, we need to take at least the first 4 bits of the commit string (4 digits below will be error). In fact, the input string is to ensure that git can accurately find the corresponding version, if the version has the first 4 duplicates, then we need to add one more, to ensure that git does not find the wrong. So many of them fit. If you use Git for a long time, you will find that many operations use this commit to shrink the top 7 bits, so we can also use the first 7 bits as the default number, of course, if the first 7 bits are still not unique, you need to enter the first 8 bits.
command: Git reflog
Time and again the fallback operation has made us forget, unconsciously already quickly back to the original version, but we also miss the new version of the good, want to go back, but git log has no new version of any footprints, we also go back to it. The answer is yes, every walk will leave traces, Git also left us a clue.
Git reflog is what git provides to us to record command history, commit and reset are all recorded in the list. With Git Reflog, we found the last commit string, and with it we can retrieve the latest version. With a skeptical attitude we have tried, and then look at git log, wow, actually went back to the state before the retreat, so that we can not roam freely between the various versions.