git diff is used to compare the difference of two revisions.
1. Compare the workspace and the staging area
git diff compares the workspace and the staging area by default without parameters
2. Compare the staging area with the latest local repository (the content of the last commit in the local repository)
git diff --cached [<path>...]
3. Compare the workspace with the latest local repository
git diff HEAD [<path>...] If HEAD points to the master branch, HEAD can also be changed to master
4. Compare the difference between the workspace and the specified commit-id
git diff commit-id [<path>...]
5. Compare the difference between the staging area and the specified commit-id
git diff --cached [<commit-id>] [<path>...]
6. Compare the difference between two commit-ids
git diff [<commit-id>] [<commit-id>]
7. Use git diff to patch
git diff > patch
The naming of patch is arbitrary, and the effect when no other parameters are added is that when we want to copy the modifications of our warehouse workspace to other machines for use, but there are many modified files and the copy amount is relatively large, at this time We can make the modified code into a patch, and then use git apply patch in the corresponding directory on other machines to apply the patch.
git diff --cached > patch is to make the difference between our staging area and the repository into a patch
git diff --HEAD > patch is to make the difference between the workspace and the repository into a patch
git diff Testfile > patch makes a single file a single patch
Extension: git apply patch applies the patch. Before applying the patch, we can check whether the patch can be applied. If there is no output from git apply --check patch, it means that the patch can be accepted smoothly.
In addition, you can use git apply --reject patch to apply the patch that can be applied first, and a .rej file will be generated if there is a conflict. At this time, you can find these files for manual patching.