Explore your commit history
The commit history is the backbone of every Git repository. It records what changed, when, and by whom. The three commands below let you read that history at different zoom levels: the full timeline, a single snapshot, or a high-level summary by contributor.
git log — Browse the timeline
git log is the starting point for any investigation. By default it lists every commit from newest to oldest. Combine it with --oneline, --graph, --author and --since / --until to zero in on what matters.
Deep dive: git log explained.
git show — Inspect a single commit
Once you've spotted a commit with git log, zoom in with git show <hash>. It prints the metadata (author, date, message) and the full diff in one output.
Deep dive: git show explained.
git shortlog — Summarize by author
git shortlog -s -n counts commits per author and sorts from most to least active. It's perfect for release notes, code reviews or onboarding onto an unfamiliar project.
Deep dive: git shortlog explained.
Search through code
Sometimes you know what you're looking for but not where it lives. git grep searches the current codebase while git log -S (the "pickaxe") finds when a string appeared or disappeared in history.
git grep — Search the working tree
git grep is faster than grep -r because it only searches tracked files and respects your .gitignore. Scope it to file types with -- "*.js", target a branch, or search all commits with --all.
Deep dive: git grep explained.
git log -S (pickaxe) — Find when a string was added or removed
The -S flag (the "pickaxe") filters git log to commits where the given string appears in the diff. If a function was deleted and you need to know when, git log -S "functionName" points you straight to the responsible commit.
Find who changed what
Tracing authorship helps you understand code decisions and ask the right person for context. git blame gives line-level annotations; git log -p shows a file's evolution over time.
git blame — Line-by-line authorship
git blame <file> annotates every line with the commit hash, author and date of the last change. It's the fastest way to answer "who wrote this line and why?" Use -L 10,20 to limit the range, or -C to detect code moved from other files.
Deep dive: git blame explained.
git log -p — Follow changes to a file
While git blame shows the current state, git log -p -- <file> shows every commit that touched that file with the full diff. It's the best way to see how a file evolved over time.
Find the bug
When a regression slips in and you have no idea which commit caused it, git bisect uses binary search to test only log2(n) commits instead of all of them.
git bisect — Binary search for bugs
Start with git bisect start, mark the current state as bad and a known working commit as good. Git checks out the midpoint for you to test. In just a few steps, even across hundreds of commits, it isolates the exact commit that broke things. Finish with git bisect reset.
Deep dive: git bisect explained.
The debugging workflow
Each command solves a narrow problem. Combined, they form a systematic debugging workflow. Here is the four-step process experienced developers follow when something breaks.
Step 1
Narrow the timeline
Use git log --oneline --since to identify the range of commits where the bug could have been introduced. Filter by date, author or file path to shrink the list.
Step 2
Identify the author
Run git blame <file> on the suspicious file to see who last modified the relevant lines. This points you to the person who has the most context.
Step 3
Pinpoint the commit
Run git bisect between a known good state and the current bad state. In a handful of steps Git isolates the exact commit that introduced the regression.
Step 4
Understand the change
Use git show <hash> on the bad commit to see the complete diff, the commit message and the author. Now you know what broke, when, and why.
This workflow scales from solo side projects to large teams with thousands of commits. The key insight: you never need to read every commit. Each tool progressively narrows the search space until you're looking at the one commit that matters.