Introduction
On this page, you can find a short description about the git status, git log, git tag, and git blame commands. Also, read their common and basic usages.
Once you have a Git repository with some history in it, most of your day-to-day work is not about changing files — it is about understanding their current and past state. Before you commit, push, or revert anything, you usually want to answer questions like: What have I changed but not yet saved? Who wrote this line, and why? When did this bug get introduced? Which release does this commit belong to?
This part of the tutorial covers the four commands you reach for most often when examining a repository rather than modifying it:
| Command | What it answers | Scope |
|---|---|---|
git status | What's changed since the last commit, and what's staged? | Working directory + staging area |
git log | What is the history of commits? | Committed snapshots only |
git tag | Which commits are notable (e.g. releases)? | Named pointers to commits |
git blame | Who last changed each line, and in which commit? | Per-line authorship of one file |
Each command is summarized below with a quick example. The following pages cover every option in detail.
git status
The git status command displays the state of the working directory and the staging area, letting you see which changes are staged for the next commit and which files are not yet tracked by Git. It does not show any committed history — only the difference between your current files and the last commit.
Run it inside any repository:
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: index.html
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: style.css
Untracked files:
(use "git add <file>..." to include in what will be committed)
notes.txtHere index.html is staged (it will go into the next commit), style.css is changed but not staged, and notes.txt is brand new and untracked. Make git status a habit before every commit so you never accidentally commit — or forget — a file.
git log
The git log command examines a repository's committed history and helps you find a particular version of a project. It lists, filters, and searches commits — but it only operates on the committed history, so anything you have not committed yet will not appear.
$ git log --oneline -3
9a3c1f4 (HEAD -> main) Fix navbar alignment on mobile
1d72b08 Add contact form validation
f0e5a91 Initial commitThe --oneline flag condenses each commit to its short hash and subject. You can filter by author (--author), by date (--since, --until), or by content (-S "searchterm") to pinpoint exactly when a change happened. To inspect a single commit in full, pair git log with git show.
git tag
Tags are references that point to specific, notable points in Git history. Their main purpose is to mark a release — for example v1.0.0. Unlike a branch, a tag does not move as you add new commits; once created, it permanently points to the same snapshot.
$ git tag v1.0.0 # create a lightweight tag on the current commit
$ git tag # list existing tags
v1.0.0
$ git tag -a v1.1.0 -m "Release 1.1.0" # create an annotated tag with a messageA lightweight tag is just a name for a commit, while an annotated tag (-a) also stores the tagger, a date, and a message — annotated tags are recommended for releases. Tags are not pushed automatically; you share them with git push origin v1.0.0 (or git push --tags).
git blame
The git blame command shows the author metadata attached to each line of a file: the commit, the author, and the date that line was last changed. It is the go-to tool for understanding why a particular line exists and who to ask about it.
$ git blame -L 1,3 index.html
9a3c1f4a (Jane Doe 2024-03-12 10:22:01 +0000 1) <!DOCTYPE html>
1d72b08c (John Roe 2024-02-28 14:05:33 +0000 2) <html lang="en">
9a3c1f4a (Jane Doe 2024-03-12 10:22:01 +0000 3) <head>The -L 1,3 flag limits output to lines 1–3. Each line is prefixed with the short commit hash, the author, and the timestamp of the last change. To dig deeper into one of those commits, copy its hash into git show or git log.
Examining vs. changing
A useful mental model: these commands are read-only. None of git status, git log, git tag (when listing), or git blame alters your files or history — they only report state. That makes them safe to run at any time. When you actually want to change what's recorded, you reach for other tools such as git commit, git checkout, or git diff to preview changes first.