Git commands

git diff

git diff: show differences between commits, branches, files, or the working directory.

The git diff command is used to display the differences between different states of your Git repository, such as the differences between your working directory and the staging area, or between two commits. It helps you see what changes have been made, which can be useful for reviewing your work before committing or for understanding the history of your project.

By default, git diff shows the differences between your working directory and the staging area. This allows you to see what changes you've made that haven't been staged for commit yet. You can also use git diff to compare specific files, branches, or commits.

git diff is particularly useful when you want to:

  • Review the changes you've made before staging or committing them.
  • Compare different versions of your project to see how it has evolved over time.
  • Identify the specific lines of code that were changed in a particular commit.
  • Understand the differences between branches before merging them.

When the output of git diff can't fit on one screen, your terminal will go into pager mode, which is designed for browsing long lists. In this mode, you can scroll through the output using the and arrow keys on your keyboard (or PageUp and PageDown to scroll faster). To exit pager mode, press q.

Examples

Show all unstaged changes in the working directory:

git diff

Show all staged changes (i.e., changes that are ready to be committed):

git diff --staged

Show changes between two commits:

git diff 1234abc 5678def

Show changes between two branches:

git diff main feature-branch

Show changes in a specific file between two branches. Note that the special -- option is used to tell Git that all the following arguments are file paths. This is necessary to avoid ambiguity when a file path may be mistaken for a branch or commit:

git diff main feature-branch -- path/to/file.js

Understanding the output

Let's consider we've modified a file named index.html by adding some new tags and modifying an existing one. Here is how the output of the git diff command might look:

Result:
diff --git a/index.html b/index.html
index 1c2s3z5..4f5g6h7 100644
--- a/index.html
+++ b/index.html
@@ -8,1 +8,3 @@
-<h1>Old header</h1>
+<h2>New header</h2>
+
+<p>New text.</p>

This output format is called a patch, and it's designed to show us what has changed in the file. Ironically, while the output is meant to be human-readable, the design choice was made in the 1970s, so it may not be as intuitive as modern interfaces. Although it may look a bit cryptic at first, there's a pattern to it. Here's how to read it:

  • The first line indicates that the diff is comparing two versions of the index.html file.
  • The second line shows the Git internal metadata. This is not important for understanding the changes in the file.
  • The --- and +++ lines and the file paths show what corresponds to the - and + lines respectively.
  • The @@ line shows the line numbers for the changes in the old and new versions of the file.
  • Lines prefixed with - were removed in the new version.
  • Lines prefixed with + were added in the new version.
  • Unchanged lines are shown for context but have no prefix.

This output tells us that:

  • The file index.html has changed, as indicated by the paths in the first few lines.
  • The line <h1>Old header</h1> has been removed.
  • It's replaced by a new line <h2>New header</h2>.
  • A new block <p>New text.</p> has been added to the bottom, as shown by a line starting with +.

A patch file like this may include multiple changes to the file, each separated by a @@ line. It may also include several files.

© 2024-2025 GitByBit.All rights reserved.

Hi! I'm Alex, creator of GitByBit.

And this is Gitopedia—a reference that summarizes knowledge in my Git course.

Gitopedia is designed to be a personal knowledge base. When you progress through the main Git course in VS Code, you unlock all of these topics, one by one, bit by bit. This gives you time to digest the information and gradually build the mental model of Git. Here's an example of how it works:

Learning directly in VS Code lets you practice Git exactly as you would in real life, doing real jobs, writing real code. In addition, the course has access to your actual terminal, so it can point out mistakes, suggest workarounds, etc.

The course is FREE, there are no Ads or other bullshit. There are optional premium add-ons you can purchase, mainly to support my work (regrettably, I have to eat every day), but that's totally up to you.

Learn Git in VS Code