git diff command is a powerful tool that you can use to see the differences between two commits, compare the changes between different versions of your code, or even identify what has changed in a particular file or set of files. Here’s how you can use
git diff to compare two different commits:
1. Identify the commits:
First, you need to identify the specific commits you want to compare. You can do this by using the
git log command. This command shows you the commit history for your repository in reverse chronological order (i.e., most recent commits first).
Each commit is identified by a unique SHA-1 hash, which is a 40-character string that might look something like this:
Typically, you only need the first 7 characters of the SHA to identify the commit.
2. Compare the commits:
Once you have identified the two commits you want to compare, you can use
git diff to compare them. You just need to enter
git diff, followed by the two commit SHAs. Here’s an example:
git diff 1a39df2 4f6ddc7
In this example,
4f6ddc7 are the SHAs of the two commits you are comparing. This command will show you what changes were made between these two commits.
3. Understanding the output:
The output of
git diff is a list of all the changes between the two commits, with deletions shown in red and additions in green (if you’re viewing it in a terminal that supports color). Each change is marked with a
- for deletions and a
+ for additions.
If you’re just interested in the names of files that changed (and not the specific changes to those files), you can add the
git diff --name-only 1a39df2 4f6ddc7
This will give you a list of filenames that changed between the two commits.
4. Compare specific files:
You can also use
git diff to compare specific files across commits. To do this, add the filename to the end of the command:
git diff 1a39df2 4f6ddc7 path/to/file
This will show you only the changes that were made to the specified file between the two commits.
git diff is a versatile command that can help you keep track of changes in your codebase, whether you’re debugging, trying to understand a past design decision, or reviewing the impact of your recent work.