Comparing the working tree with the repository
Imagine you're working on your hello.html, and a mischievous cat runs over your keyboard, adding a bunch of nonsense to your file. You've gone from a well-crafted Hello, World! to a page full of cat gibberish.
A nasty little cat runs over your keyboard, making random changes to hello.html.
After the feline interruption, let's check whether anything has been changed. git status is the go-to command for this purpose, showing you the current state of your working tree and the repository.
Run the git status command to check the status of the repository.
From the output of the git status command, we can see that the hello.html file has been modified:
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: hello.html
no changes added to commit (use "git add" and/or "git commit -a")
Let's find out what exactly has been changed. You could open the file and look for the cat's contribution, but that's not very efficient. What if the file is large, or the cat has been particularly prolific?
The git diff command comes to the rescue, showing you exactly what has been modified in your working tree compared to the version in the repository. By default, it compares to what you have in the staging area (which hasn't had any new changes since the last commit, so effectively we're comparing to the last commit).
git diffCheck the difference between the working tree and the repository.
Tip: 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. To exit pager mode, press q.
You should see something like this:
diff --git a/hello.html b/hello.htmlindex 8ab686e..95f1408 100644--- a/hello.html+++ b/hello.html@@ -1 +1 @@-Hello, World!\ No newline at end of file+Hello, Meow! World! Meow! Meow! Meow!\ No newline at end of fileThis output format is usually called a patch, and it's supposed to tell you what has changed in the file. Ironically, the output is designed to be human-readable, but that was a design choice made in the 1970s, so it may not be as intuitive as modern interfaces. In any case, while 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.htmlfile. - 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 you:
- The file
hello.htmlis changed as indicated by the paths in the first few lines. - There's a removal of the line
Hello, World! - It's replaced by a new line
Hello, Meow! World! Meow! Meow! Meow!
This is a clear sign of our cat's "contribution". With git diff, you can review changes line by line, making it easier to spot unintended modifications. When you have a clear picture of what's been changed, you can decide whether to keep the changes, discard them, or modify them further.
The git diff command accepts a variety of arguments to compare different things. For example, git diff HEAD compares the working tree with the latest commit of the current branch, whereas git diff 4620193 example.html would compare the example.html file in the working tree with the said file at the commit number 4620193.
We will get rid of the cat's gibberish and restore the original Hello, World! with another helpful Git command in the next step.
Hi! I'm Alex, creator of GitByBit.
This page is a part of the interactive course about Git version control.
It's a one-of-a-kind course that is integrated into the VS Code code editor. Learning directly in VS Code lets you operate 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.