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:
Terminal
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:
Terminal
$ git status -s
Hover over each part to see what it does
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:
Terminal
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:
Terminal
$ git diff src/utils/helpers.ts
# Shows only the changes in that specific file
$ git diff --stat
src/App.tsx | 12 ++++++------
src/utils/helpers.ts | 8 +++++---
2 files changed, 11 insertions(+), 9 deletions(-)
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 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:
Git's three areas
Working tree Staging area Repository
(your files) (git add) (git commit)
| | |
|--- git diff ------>| |
| |--- git diff --staged->|
| |
|------------ git diff HEAD --------------->|
$ git diff
Hover over each part to see what it does
$ git diff --staged
Hover over each part to see what it does
$ git diff HEAD
Hover over each part to see what it does
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:
Komitly - Staging Panel
Staged (2)
Msrc/App.tsx
Asrc/components/Header.tsx
Changes (3)
Msrc/utils/helpers.ts
Dsrc/old-config.json
?src/components/Footer.tsx
Add header component and update imports
Commit
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:
Komitly - Diff Viewer
src/utils/helpers.ts
@@ -5,7 +5,9 @@ export function formatPrice(amount: number) {
11 const formatter = new Intl.NumberFormat('en-US', {
22 style: 'currency',
3- currency: 'USD',
3+ currency: 'USD',
4+ minimumFractionDigits: 2,
5+ maximumFractionDigits: 2,
46 });
57 return formatter.format(amount);
68}
@@ -18,6 +20,10 @@ export function slugify(text: string) {
And here is a file with more structural changes — imports reorganized and new components added:
Komitly - Diff Viewer
src/App.tsx
@@ -1,8 +1,10 @@
11import { useState } from 'react';
2-import './App.css';
2+import './styles/global.css';
3+import Header from './components/Header';
34
45function App() {
5- const [count, setCount] = useState(0);
6+ const [page, setPage] = useState('home');
67
78 return (
8- <div className="App">
9+ <div className="app-container">
10+ <Header onNavigate={setPage} />
911 </div>
1012 );
1113}
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:
Terminal
# 1. Check what changed
$ git status
# 2. Review unstaged changes in detail
$ git diff
# 3. Stage the files you want
$ git add src/App.tsx src/components/Header.tsx
# 4. Verify what will be committed
$ git diff --staged
# 5. Commit with confidence
$ git commit -m "Add header component and update imports"
[main f8a9b0c] Add header component and update imports
2 files changed, 18 insertions(+), 5 deletions(-)
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:
End-of-session review
# 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 and verify
# 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.