preface

In previous articles, we covered the basics of git Add, Git commit, and Git push, as well as how to set up a gitignore file that allows you to use Git Add. To add the files we want without having to manually separate them.

Git diff: git diff: git diff: git diff: Git diff: Git diff: Git diff

git diff

Git diff is a very handy command that many people use to see code changes because it is very convenient. Git diff allows you to see the difference between the current workspace and the staging area, which means you can see the code that is currently being modified or added, but not yet added to the staging area. It lists before and after changes for easy viewing and modification.

For example, if I run git diff on a random repo without adding any parameters, I extract a snippet from the result as follows:


Since I configured ZSH, it highlights the comparison before and after the change. In the example above, we delete one row and add two. We can easily view the changes before and after, so that we can check whether the logic of the change is wrong.

Git diff + file path

Git diff displays all file changes by default if you don’t add any parameters. At this point we can add the file name, see a specific file changes. Git diff shell/prepare_data.sh is the path of the shell file, and the other changes are invisible.


git diff –cached

As mentioned above, what we see without any arguments is the difference between the code in the workspace (before the add command) and the staging area. If we have added all the code, we will not see anything when we run Git diff. Git diff: git diff: git diff:


You can see that all of the previous changes are gone, because we have committed the code to the staging area, which is the difference between workspace and staging without parameters. The difference between the staging area and the local Git repository is the difference between changes that have been added and not yet committed. You can do this by using the –cached parameter, which 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 changes are displayed again.


Other USES

Git diff has several other uses besides the methods just mentioned. For example, it can also be compared with a certain commit and another branch. These commands are relatively uncommon, so let’s list them briefly:

Compare workspaces with a particular commit
git diff <commitid>

Compare the difference between workspaces and submissions
git diff <commitid> <filepath>
 Compare the difference between a staging area and a commit git diff --cached <commitid>  Compare the difference between staging and submitting a file git diff --cached <commitid> <filepath> Copy the code

git log

The Git log, which you may have heard of and whose purpose you might not have guessed from its name, displays all the commits on the current branch.

For example, if I run the Git log on the repo where the Git articles are stored, I can see the previous commit record:


There are two important bits of information in the log that I’ve highlighted in red. This is the commit ID, which is unique in the Git repository and can be used to lock a commit. For example, compare git diff to a commit, and the commitid passed in is this.

There is no need to copy the entire id, because it is too long. In fact, Git has auto-complete, so we usually just copy the first few bits. For example, git diff dfD55 is sufficient. Git will find a commit that meets the criteria based on the number of bits we enter. The first few bits are usually enough to lock a commit.

The second key information is the commit information, which is the string we enter after each commit -m, which indicates what changes were made in the commit. This is written by the developer and is also the key information.

git log -p

When you run the Git log, it will only display the information related to the commit. It will not display every change. It is not necessary, and it is too much. Sometimes we want to see what changes were made in each commit, and git diff can be a hassle. You can do this with a parameter. Just add -p to the git log and it will show you every commit change.


In fact, we can also see from the header log information, it is also implemented through git diff. Since the changes in the COMMIT can be quite large, we can see a lot of things this way. We can behind – p plus a – n said we want to see the recent several commit information, such as the git log – p – 2 view is two recently submitted information.

git log –stat

The stat parameter can be used in situations (such as when HR determines performance based on code) where we just want to see how many changes are made per commit, rather than what the changes are.

It tells us how many changes were made to each file in the commit, so we can see the file-specific changes.


git log –pretty

The Pretty parameter is a magic tool that allows us to diy the log display we want to see. Git log –pretty=oneline — git log — git log –pretty=oneline


We can see that it omits author, time, etc., and only keeps the commitiD and comment information. This is usually used when troubleshooting problems where you want to quickly find a commit. In addition to Oneline, there are several other formats available, such as Short, Full, and Fuller, which offer slightly different information for you to try.

Finally, a great use is to define the output we want. For example, I want to see a log that contains the commitiD, submission time, author and comment. Then we can define a format: % H – % AD – %an – %s. So the command we execute is:

git log --pretty=format:"%h - %ad - %an - %s"
Copy the code

The result would be:


This is exactly what we want, %h and % AD are actually official parameters, they represent one kind of information. For example, %h indicates the short commitid, % AD indicates the submission time, % AN indicates the author information, and %s indicates the comment during the submission. Of course, there are more parameters to choose from. There is a table that can be selected from the table.


Git log can also be used with a –graph, which shows a tree branch structure submitted. It is also very, very useful, but I couldn’t find a suitable repo to show, so I’ll show you an official example:


Git logs have a few other features that are relatively uncommon and will not be covered here. If you are interested, you can check out the official documentation and experience the power of git commands.

conclusion

Git diff, git log, git diff, git diff This is perfectly normal, because Git is for all developers, and different developers have different habits, some of whom have their own special needs. Therefore, Git is designed to be very complex and powerful, and can achieve a variety of functions. It is not necessary for us to learn all of them. We should make choices according to our daily needs.

I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.

Original link, ask a concern

This article is formatted using MDNICE

– END –