Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the commonly used and important commands in git". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the commonly used and important commands in git.

Git diff

Git diff is a very useful command, and a lot of Daniel uses it to check for code changes, because it's really convenient. The git diff command can see the difference between the current workspace and the staging area, that is, you can see the code that we have modified or added, but there is no add into the staging area yet. It will list the comparison before and after the changes, making it easy for us to view and modify them.

For example, I randomly found a repo to run git diff without adding any parameters. I intercepted a fragment from the result as follows:

Because I configured zsh, it will highlight the content comparison before and after the modification. For example, in the above example, we deleted one line and added two lines. We can easily check the changes before and after, and it is convenient for us to check whether there is anything wrong with the logic of the changes.

Git diff + file path

Of course, if git diff does not add any parameters, it will show all the file changes by default, sometimes we have a large amount of changes, it will look tired. At this time, we can add the file name to check the specific changes to a certain file. For example, the changes in the above example take place in a shell file. I can run git diff shell/prepare_data.sh directly, that is, the path corresponding to the shell file, and I will find that no other changes can be seen.

Git diff-cached

As mentioned earlier, what we are looking at without any parameters is the difference between the code in the workspace (before the add command) and the staging area. If we have add all the code in, then when we run git diff, it won't show anything. For example, we submit all the code in the warehouse just now, and then run git diff. The result is as follows:

You can see that all the changes just now are gone, because we have submitted the code to the staging area, and when we do not add parameters, it is the difference between the workspace and the staging area. At this time, we want to see diff again, what we want to see is the difference between the temporary storage area and the local git warehouse, that is, it has been add and has not been changed by commit. At this point, we can do this with the-- cached parameter, and the-- cached parameter can also be followed by the file name to view a specific file.

For example, when we execute git diff-cached shell/prepare_data.sh, the previous changes are shown again.

Other uses

In addition to the methods just mentioned, git diff has some other uses. For example, it can also be compared with a definite submission and another branch. These commands are relatively uncommon, so let's briefly enumerate them:

# compare the difference between a workspace and a submission git diff # compare the difference between a workspace and a submission git diff # compare the difference between a temporary storage area and a submission git diff-cached # compare the difference between a temporary storage area and a submission git diff-cached git log

You may have heard of git log, and even if you don't, it's not hard to guess the use from the name, which shows all the submissions on the current branch.

For example, when I run git log under the repo where git articles are stored, I can see the previous submission record:

There are two important pieces of information in log that I highlighted with a red pen. One of them is a long list followed by commit, and this is commit id, which is unique in the git repository, and we can use it to lock a commit. For example, when git diff is compared with a certain commit mentioned above, this is the commitid passed in.

We do not need to copy all the id, because it is too long, in fact, git has automatic completion function, we usually copy the first few bits. For example, git diff dfd55 is enough. Git will find a qualified commit based on the bits we typed. Generally speaking, the first few bits are enough to lock a commit.

The second key information is the submission information, that is, the string we enter after each commit-m, which indicates what has been changed in the commit. This is written by the developer and is also a key prompt.

Git log-p

When we run git log, we will only show the relevant information about submission, and we will not show the content of each change. On the one hand, it is not necessary, and on the other hand, it is too much. But sometimes we want to see what's changed in each commit, and it's too troublesome to check it one by one through git diff. At this point, you can use parameters to do this, just add-p after the git log, and it will show the changes in each commit.

In fact, we can also see from the log information in the header that the underlying layer is also implemented through git diff. As the amount of change in commit may be very large, so we will see a lot of content in this way. We can add a-n after-p to indicate the last few pieces of commit information we want to view, such as git log-p-2 looking at the last two submissions.

Git log-stat

Sometimes (for example, HR determines performance based on code) we just want to see how much change there is in commit each time, and we don't want to know what the change is, so we can use the stat parameter.

It will tell us how many changes have been made to each file in the commit, so that we can see the changes specific to the file.

Git log-pretty

The pretty parameter is an artifact that allows us to diy the log presentation we want to see. For example, git log-pretty=oneline is commonly used, where oneline is a format that represents a single-line display, that is, it compresses the information displayed by commit into one line.

We can see that it omits author, time and other information, leaving only commitid and comment information. This is commonly used when troubleshooting problems when you want to find a commit quickly. In addition to oneline, officials also provide several other format, such as short, full and fuller, which show slightly different information. You can try it yourself.

Finally, an awesome usage is introduced, that is, we define the output we want. For example, the log log I want to see should include commitid, submission time, author, and comment. Then we can define a format ourselves:% h -% ad -% an -% s. So the orders we carry out are:

Git log-- pretty=format: "% h -% ad -% an -% s"

The result will be:

This is exactly what we want, and the% h and% ad here are actually official parameters, and they each represent a kind of information. For example,% h represents short commitid,%ad for submission time,% an for author information, and% s for comment at the time of submission. Of course, there are more than these optional parameters, the official provides a table, the parameters in the table can be selected.

The use of another parameter for git log is-- graph, which shows a tree branch structure of the submission. It's also very easy to use, but I can't find a suitable repo presentation, so I'll show it to you with an official example:

Thank you for your reading, the above is the content of "what are the commonly used and important commands in git". After the study of this article, I believe you have a deeper understanding of the common and important commands in git, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.