git status & git diff: Understanding What Changed

Why git status and git diff matter

If git commit is the save button, then git status and git diff are the preview screen. They answer the two most important questions you will ask yourself dozens of times a day: what has changed? and what am I about to commit?

Running git status gives you a high-level overview — which files were modified, which are staged, which are new. Running git diff shows you the exact lines that changed inside each file. Together, they give you complete visibility into the current state of your repository before you make any decisions.

A good habit: always run git status before staging, and git diff --staged before committing. It takes two seconds and prevents accidental commits with debug code, leftover console.log calls, or files you did not intend to include.

Reading git status

The output of git status is organized into three sections, each representing a different state your files can be in. Here is a typical example after modifying a few files:

The three sections

• Changes to be committed — These files are in the staging area (the index). They will be included in your next commit. You put files here with git add.
• Changes not staged for commit — These files have been modified or deleted, but the changes are only in your working tree. They will not be committed unless you stage them first.
• Untracked files — Brand new files that Git has never seen before. Git will ignore them completely until you explicitly add them with git add.

Short format

For a more compact view, use the -s flag. It shows each file on a single line with a two-letter status code:

The two-column format takes a moment to learn but quickly becomes second nature. The left column shows the status in the staging area and the right column shows the status in the working tree. The most common codes are:

• M — Modified
• A — Added (new file staged for the first time)
• D — Deleted
• ?? — Untracked (Git has never seen this file)

For example, M  src/App.tsx means the file is modified and staged (left column), while  M src/utils/helpers.ts means the file is modified but not staged (right column).

Understanding git diff

Where git status tells you which files changed, git diff tells you exactly what changed inside them — line by line. Here is what a typical diff looks like:

Anatomy of a diff

The diff output can look intimidating at first, but it follows a simple pattern:

• Header lines (diff --git, index, ---, +++) — Identify which file is being compared and which versions are involved.
• Hunk header (@@ -5,7 +5,9 @@) — Shows the line range in the old file (-5,7) and new file (+5,9). The text after @@ is the nearest function name for context.
• Context lines (no prefix) — Unchanged lines shown for surrounding context.
• Removed lines (- prefix, red) — Lines deleted from the old version.
• Added lines (+ prefix, green) — Lines added in the new version.

A modified line shows up as a removal followed by an addition. Git does not have a concept of "modified lines" — it only knows about additions and deletions.

Useful diff flags

You can narrow down or change the output of git diff with flags:

• git diff <file> — Show changes for a single file only.
• git diff --stat — Show a summary with file names and insertion/deletion counts. Great for a quick overview.
• git diff --word-diff — Highlight changes at the word level instead of entire lines. Useful for prose or long strings.
• git diff -w — Ignore whitespace changes. Helpful when reformatting code.

Comparing different states

Git manages your files across three areas: the working tree (the actual files on disk), the staging area (what you have added with git add), and the repository (committed snapshots). The git diff command can compare between any two of these:

Working tree          Staging area          Repository
(your files)         (git add)             (git commit)
     |                    |                      |
     |--- git diff ------>|                      |
     |                    |--- git diff --staged->|
     |                                           |
     |------------ git diff HEAD --------------->|

Understanding which diff command compares which areas is the key to never being surprised by what ends up in a commit. When in doubt, run git diff --staged right before committing — it shows you the exact snapshot you are about to save.

Visual diffs in Komitly

Reading diffs in the terminal works, but a visual tool makes the experience dramatically better. Komitly replaces the wall of + and - signs with a color-coded diff viewer that shows additions, deletions, and context at a glance.

The staging panel gives you an instant git status — every file is categorized as staged or unstaged, with a status badge showing whether it was added, modified, or deleted. Click any file to move it between sections:

Click on a file in the real app and Komitly opens the diff view automatically. Here is what the diff looks like for a modified utility file:

And here is a file with more structural changes — imports reorganized and new components added:

Four diff modes

Komitly goes beyond a simple diff view. You can switch between four modes using the toolbar at the top of the diff viewer:

• Unified — The classic view. Old and new lines interleaved, just like git diff in the terminal but with syntax highlighting.
• Split — Side-by-side comparison. The old version on the left, the new version on the right. Makes it easy to see exactly what was replaced.
• Word diff — Highlights changes at the token level. Instead of showing an entire line as removed and re-added, it marks only the specific words that changed.
• Semantic diff — Detects moved blocks and renames. If you moved a function to a different location in the file, a normal diff shows it as a deletion plus an addition. Semantic diff recognizes it as a move.

You can also toggle syntax highlighting, whitespace visibility, and word wrap — all from the diff viewer header. Combined with hunk staging (click the gutter to stage individual hunks or lines), you get complete control over what goes into each commit without ever opening a terminal.

In Komitly, git status is the staging panel and git diff is the diff viewer. The same information, but visual, interactive, and always up to date.

Common workflows

The pre-commit checklist

This five-step workflow ensures you never commit something by accident. It only takes a few seconds and quickly becomes muscle memory:

Checking what you changed after a long session

After hours of coding, it is easy to lose track of everything you touched. Use git diff --stat for a quick summary and then dive into individual files:

# Quick overview of all changes
git diff --stat

# Detailed diff for a specific file
git diff src/utils/helpers.ts

# See ALL changes (staged + unstaged) vs last commit
git diff HEAD

Reviewing staged changes before committing

This is arguably the most important habit to develop. After staging your files, always verify the staged diff:

# Stage specific files
git add src/App.tsx src/components/Header.tsx

# Review exactly what will be committed
git diff --staged

# Happy? Commit.
git commit -m "Add header component and update imports"

In Komitly, this workflow happens naturally. The staging panel shows your files, clicking a file reveals its diff, and the commit button is right below. Everything you need in one view — no commands to memorize.

Summary

git status and git diff are the commands you will run most often. They keep you informed about the state of your repository and prevent surprise commits. Here is a quick recap:

• git status shows which files are staged, modified, or untracked. Use -s for a compact view.
• git diff shows the line-by-line changes in your working tree (unstaged changes).
• git diff --staged shows what will be included in the next commit. Always check this before committing.
• git diff HEAD shows all changes (staged and unstaged) compared to the last commit.
• Use --stat for a summary, --word-diff for granular changes, and -w to ignore whitespace.
• In Komitly, the staging panel replaces git status and the diff viewer replaces git diff — with four viewing modes, syntax highlighting, and hunk-level staging built in.

With git status and git diff in your toolkit, you always know exactly what has changed and what is about to be committed. Next, learn how to sync your work with teammates using git pull and git push.