Every commit tells a story. But with thousands of them stacking up across branches, finding the one that matters takes more than scrolling.
So, what is git log? It’s the Git command that gives you access to your repository’s full commit history, with filters, formatting options, and search capabilities most developers barely scratch the surface of.
Whether you’re tracking down a bug, reviewing what your team shipped last week, or trying to figure out when a specific line of code was added, git log is the starting point.
This guide covers how the output is structured, the most useful command options, how to format and filter results, how git log handles branch and merge history, and how it compares to git reflog. You’ll also see how it performs on large repositories, how it fits into debugging workflows, and which GUI tools display the same data visually.
What is Git Log
Git log is a command that displays the commit history of a git repository. It reads from the .git directory’s object database and prints a reverse-chronological list of every commit on the current branch.
Each entry in the output includes four pieces of information: the commit hash (a unique SHA-1 identifier), the author’s name and email, the timestamp, and the commit message.
That’s the default behavior. No flags, no options. Just git log and you get the full history dumped into your terminal pager.
Linus Torvalds built Git in 2005 specifically to manage the Linux kernel. The kernel recorded 75,314 commits in 2024 alone, according to Command Linux research. Every single one of those commits is accessible through git log.
It belongs to a family of inspection commands alongside git diff, git blame, and git show. But git log is the starting point for most history-related tasks. You look at the log first, then dig deeper with the others.
One thing worth calling out. Browsing commits on GitHub or GitLab is not the same as running git log locally. Those web interfaces show a simplified view. The command line version gives you access to every filtering and formatting option Git offers, which is a lot more than most people realize.
RhodeCode data shows Git adoption rose from 87.1% in 2016 to 93.87% in 2025. Nearly every developer working with version control today is using Git, and git log is one of the first commands they’ll run after cloning a project.
How Git Log Output is Structured
Run git log with no arguments and each commit fills about five lines in your terminal. Knowing what each line means is the difference between scanning history quickly and staring at hashes wondering what happened.
The Commit Hash
The first line starts with commit followed by a 40-character hexadecimal string. That’s the commit hash, a SHA-1 checksum of the commit’s contents.
Git is migrating toward SHA-256 in newer versions, but SHA-1 remains the default for most repositories. You rarely need the full 40 characters. Git can identify commits with the first 7 characters in most cases.
Author Information and Timestamp
Author line: Shows the name and email pulled from git config at the time the commit was made.
Date line: Displays the commit timestamp with timezone offset. The default format is something like Mon Mar 10 14:32:07 2025 -0500.
Timezone handling trips people up on distributed teams. A developer in Tokyo and one in Berlin will show different timezone offsets on their commits, even if they committed within seconds of each other.
Commit Message and HEAD Pointer
Below the date sits the commit message, indented with four spaces. The first line of the message (the subject) is what shows up in compressed views like --oneline.
You’ll also see branch and tag references next to the hash on certain commits. Something like (HEAD -> main, origin/main). That tells you where the HEAD pointer currently sits and which branches point to that commit.
Hutte research found that 77% of developers consider the commit history in a version control system a form of documentation. Clean, readable log output directly supports that.
Git Log Command Syntax and Common Options
The base syntax is git log [options] [revision range] [-- path]. Everything after git log is optional. But the options are where git log becomes actually useful.
Here are the flags most developers reach for daily:
| Flag | What It Does | When to Use It |
|---|---|---|
| –oneline | Compresses each commit to one line | Quick scanning of recent history |
| –graph | Draws ASCII branch topology | Seeing merge and branch structure |
| –all | Includes all branches | Viewing full repository history |
| -n | Limits output to n commits | Checking recent activity |
| –since / –until | Date-based filtering | Reviewing work within a time window |
Hutte statistics indicate that 65% of developers still prefer using Git through the command line over a graphical interface. These flags are likely part of their daily routine.
Filtering Commits by Author and Date
The --author flag accepts a string and matches it against the author field. It’s not exact match. It uses regular expression matching, so --author="Jane" catches “Jane Smith” and “Janet Doe.”
Date filtering supports both ISO 8601 formats and relative expressions. --since="2 weeks ago" works just as well as --since="2025-03-01".
You can combine these. git log --author="Jane" --since="1 month ago" shows only Jane’s commits from the past month. Took me a while to realize you could stack filters like that when I first started.
Filtering Commits by File Path
Pass -- <path> after your options to scope history to specific files or directories.
Why this matters: Large repositories can have hundreds of thousands of commits. The Linux kernel crossed 40 million total lines of code with version 6.14 rc1 in early 2025 (Command Linux). Running git log against a codebase that size without path filtering is basically useless.
There’s a difference between path filtering and git log -p. Path filtering limits which commits appear. The -p flag (patch output) shows the actual diff for each commit. You can use both together to see diffs only for a specific file.
Formatting Git Log Output
The default output works fine for a quick check. But if you need to pipe log data into another tool, or you just want something easier to scan, Git gives you deep control over formatting.
Pretty Format Strings
--pretty=format: is the flag that unlocks custom output. You write a format string with placeholders, and Git fills them in for each commit.
Common placeholders:
%H– full commit hash%h– abbreviated hash%an– author name%s– commit subject line%ad– author date
So git log --pretty=format:"%h %an %s" gives you a clean, compact output with just the hash, author, and message. Perfect for scripting.
Developers working in DevOps pipelines use format strings regularly to generate changelogs or feed commit data into monitoring tools. GitHub’s Octoverse 2025 report found that developers pushed nearly 1 billion commits in 2025. Automation around commit history isn’t optional at that scale.
Built-in Formats and Date Options
If custom format strings feel like overkill, Git ships with built-in presets.
short – shows hash, author, and subject only.
full – adds committer info alongside author info (they can differ).
oneline – the most compact view, equivalent to --oneline.
The --date= option controls how timestamps render. --date=relative shows “3 days ago” instead of a full timestamp. --date=short gives just the date portion, like 2025-03-10.
I prefer --date=relative for quick checks and --date=iso when I’m filtering commits for a report. Your mileage may vary depending on whether you’re scanning or analyzing.
Git Log with Branch and Merge History
Branches are where git log gets complicated. And also where it becomes most valuable.
Around 60% of teams use a feature-branch workflow, while 25% adopt Git Flow or a similar structured approach, according to Hutte research. All of these workflows produce merge commits that show up in your log.
Visualizing Branches with –graph
The --graph flag draws ASCII art lines showing how branches split and merge. Combine it with --oneline and --all for the best results:
git log --graph --oneline --all
This is the command most people alias to something short like git lg. It gives you a bird’s-eye view of your entire repository topology in seconds.
When you’re trying to merge two branches in Git, the graph view helps you understand where they diverged before you start the merge.
Range Notation for Branch Comparison
Double-dot (..): git log main..feature shows commits in feature that aren’t in main. This is what you’d check before opening a pull request.
Triple-dot (…): git log main...feature shows commits that are in either branch but not both. Good for seeing total divergence.
The double-dot operator is by far the more common one. If you only remember one, remember that.
Handling Merge Commit Clutter
Merge commits pile up fast. Hutte data shows that 87% of Git users have encountered merge conflicts at some point. Every resolved conflict produces a merge commit that shows up in your log.
--no-merges strips them out for a cleaner view of actual work done.
--first-parent follows only the first parent of each merge, giving you a linear view of the main branch history. This is how most git workflows expect you to read history.
Both flags are about noise reduction. On a busy project with multiple contributors, the raw log can be unreadable without one of these.
Git Log vs. Git Reflog
These two get mixed up constantly, and the confusion makes sense. Both show history. But they track completely different things.
| Feature | git log | git reflog |
|---|---|---|
| What it tracks | Commit history reachable from branch tips | Every movement of HEAD locally |
| Scope | Shared across clones | Local to your machine only |
| Survives push/pull | Yes | No |
| Primary use | Reviewing project history | Recovering from mistakes |
Git log shows the “official” history. It’s what everyone on the team sees.
Git reflog is your personal safety net. It records resets, rebases, checkouts, and anything else that moves HEAD. Even if you reset to an earlier commit and “lose” recent work, the reflog still has the SHA of those commits. You can revert to a previous commit using those references.
Hutte’s findings show that 92% of developers have had to roll back to a previous version of their code at least once. That’s where reflog saves you, not git log.
When Reflog Beats Git Log
You ran a rebase that went wrong. Or you did a hard reset and immediately regretted it.
git reflog shows you the commit hash from before your mistake. From there, git checkout or git reset --hard gets you back.
Git log won’t help here because the commits you need are no longer reachable from any branch tip. They’re “dangling” in the object database. The reflog is the only thing still pointing to them.
One thing to keep in mind. Reflog entries expire. By default, Git prunes them after 90 days (30 days for unreachable commits). So the safety net isn’t permanent.
Git Log in Practice with Large Repositories
Running git log on a small project feels instant. Running it on a repository with a million commits is a different story.
The Linux kernel has over 1.3 million commits from roughly 29,380 different authors, according to Phoronix’s 2024 GitStats analysis. Chromium’s repository exceeds 60 GB in total size. At that scale, every git log command needs to be scoped down or it becomes unusable.
Performance Strategies for Huge Histories
Pagination: Use -n and --skip together to page through commits. git log -n 20 --skip 100 grabs commits 101 through 120.
Commit graph cache: Git’s commit-graph file (enabled through git maintenance) indexes commit parent relationships so commands like git log --graph don’t have to open objects one at a time. GitButler benchmarks show this makes log-related commands on the Linux kernel significantly faster.
The GitHub Blog documented that git status on the Chromium repository (about 400,000 files) dropped from 17 seconds to roughly 1 second after enabling FSMonitor. Git log benefits from similar internal optimizations.
Tracking File Renames and Shallow Clones
git log --follow is the flag you need when a file has been renamed. Without it, git log stops at the rename point and shows nothing before it.
Shallow clones (--depth=1) create a tricky situation. You get only the latest commit, which means git log shows almost nothing. GitLab benchmarks show optimized shallow clones cut Chromium’s clone time from 95 minutes down to under 7 minutes, but the tradeoff is losing access to full history.
If you need the full log later, git fetch --unshallow retrieves the missing history. But on a project that size, that fetch takes a while.
Partial clones with --filter=blob:none offer a middle ground. You get all the commits (so git log works normally) without downloading every blob. Microsoft uses this approach on massive internal source control repositories.
Using Git Log for Code Review and Debugging
Git log isn’t just for reading history. It’s a debugging tool. Combined with the right flags, it helps you find when code was introduced, when it changed, and who touched it last.
Hutte research shows that 80% of senior developers recommend committing changes frequently with small, incremental commits. That discipline pays off directly when you need to search through the log later.
Viewing Diffs Inline with Commits
git log -p (or --patch) appends the full diff to each commit entry. You see exactly what changed, line by line.
This is the flag I reach for most during code review. Instead of clicking through a web interface, git log -p --author="teammate" --since="yesterday" shows everything they pushed in one scroll.
Combine it with --stat if you want a summary first: file names, insertions, and deletions per commit.
Pickaxe Search and Regex Matching
Two flags turn git log into a code search engine.
| Flag | What It Finds | Best For |
|---|---|---|
| -S “string” | Commits that added or removed the string | Finding when a function was introduced |
| -G “regex” | Commits where the diff matches the pattern | Searching for pattern-based changes |
| –grep “text” | Commits whose message matches the text | Finding commits by description |
The -S flag (called “pickaxe”) is the one most people don’t know about. It answers the question: “When did this specific piece of code first appear in the project?” Or the reverse: “When was it deleted?”
On a project with thousands of commits, this saves hours compared to manually scrolling through diffs.
Combining Git Log with Git Bisect
Git bisect uses binary search to find the commit that introduced a bug. Git log is what you use before and after bisect to understand context.
Typical workflow: Run git log --oneline to identify a known good commit. Start bisect. Let it narrow things down. Once it finds the bad commit, run git log -p on that commit to see exactly what broke.
With 1,000 commits to search, bisect finds the culprit in about 10 steps instead of 500. That’s O(log n) complexity applied to debugging. The log command provides the entry and exit points for the whole process.
Piping Git Log Output to Other Tools
Because git log outputs plain text, you can chain it with standard Unix tools.
git log --oneline | grep "fix"finds all commits mentioning “fix”git log --pretty=format:"%an" | sort | uniq -c | sort -rnlists contributors by commit countgit shortlog -sndoes the same thing but built in
Developers working in continuous integration pipelines regularly pipe git log data into scripts that generate release notes or trigger build pipeline steps based on commit patterns.
GitHub Actions workflows consumed 11.5 billion minutes during 2024-2025, a 35% year-over-year increase according to Mordor Intelligence. A lot of those workflows parse git log output as part of their automation.
Git Log in GUI Tools and Hosting Platforms
Not everyone lives in the terminal. GUI clients and web-based hosting platforms present the same commit history data that git log shows, but in a visual format with clickable elements and branch graphs.
Desktop GUI Clients
The most common standalone clients for browsing commit history:
GitKraken: Known for its visual commit graph. Works on Windows, Mac, and Linux. Gitkraken acquired the GitLens VS Code extension, which brings inline git log data directly into the editor.
Sourcetree: Free, built by Atlassian. Strong search functionality for finding specific commits. Doesn’t support Linux, which is a dealbreaker for some teams.
Fork: A newer option that’s gained fans for raw speed and a cleaner diff viewer.
These tools all render the same data git log --graph --all produces. The difference is that they make branch topology immediately visible without memorizing ASCII art.
Web-Based Commit History Views
GitHub, GitLab, and Bitbucket each have commit history pages that mirror what git log shows. GitHub’s interface lets you filter by branch, author, and date range. GitLab adds features like blame views and contribution analytics.
GitHub now hosts over 180 million developers and more than 630 million repositories, per the Octoverse 2025 report. Most of those developers first encounter commit history through the web UI, not the terminal.
But web interfaces have limits. You can’t do pickaxe searches through the GitHub UI. You can’t use custom --pretty=format strings. You can’t pipe output to grep. For anything beyond basic browsing, you end up back at the command line.
Terminal-Based Alternatives
tig is a text-mode interface for git. It gives you an interactive view of the log that you can scroll, search, and drill into, all without leaving the terminal.
It’s particularly useful on remote servers where you only have SSH access and no GUI is available. You can use Git through tig for history browsing while keeping the full CLI available for everything else.
Lazygit is another terminal UI that wraps common Git commands in a keyboard-driven interface. Both tools read from the same object database that git log does.
FAQ on What Is Git Log
What does git log show by default?
It displays a reverse-chronological list of commits on the current branch. Each entry includes the commit hash, author name, date, and commit message. No flags needed, just run git log in your terminal.
How do I limit the number of commits git log displays?
Use the -n flag followed by a number. For instance, git log -5 shows only the last five commits. Useful when you just need a quick look at recent commit history without scrolling through everything.
What is the difference between git log and git reflog?
Git log shows the commit history reachable from branch tips. Git reflog records every local HEAD movement, including resets and rebases. Reflog is local only and doesn’t transfer when you push to a remote repository.
How do I search for a specific string in git log?
The -S flag (pickaxe search) finds commits that added or removed a given string. Run git log -S "functionName" to trace when that piece of code first appeared or was deleted from the project.
Can I filter git log by author?
Yes. Use --author="name" to show only commits from a specific person. It supports regex matching, so partial names work too. Combine it with --since to narrow results to a date range.
What does git log –oneline do?
It compresses each commit into a single line showing the abbreviated hash and subject. This is the fastest way to scan history on a busy repository. Most developers alias it to something short like git lg.
How do I see which files changed in each commit?
Add the --stat flag. It shows file names, lines added, and lines removed per commit. For the full diff of every change, use git log -p instead. Both work with other filtering options.
How do I view branch history with git log?
Run git log --graph --all --oneline to see an ASCII diagram of all branches. The –graph flag draws lines showing where branches split and merge. It’s the quickest way to understand your repository’s topology.
Does git log work with file paths?
Yes. Append -- filename to scope results to a specific file. Add --follow if the file was renamed at some point. Without that flag, git log stops at the rename and hides earlier history.
How do I customize the output format of git log?
Use --pretty=format: with placeholder strings like %h for short hash, %an for author, and %s for subject. This is how teams build automated changelogs and feed commit data into continuous deployment pipelines.
Conclusion
Understanding what is git log goes well beyond memorizing a single command. It’s about knowing how to inspect your project’s revision history, filter commits by author or date range, and format output for scripts or quick scanning.
The real value shows up when you combine it with flags like -S for pickaxe search, –graph for branch topology, or -p` for inline patch output. These options turn a basic history viewer into a proper debugging and code refactoring tool.
Whether you work in the terminal, through a GUI client like GitKraken or Sourcetree, or browse commits on GitHub versus plain Git, the underlying data is the same. Git log reads it. Everything else just presents it differently.
Learn the flags that match your daily workflow. Alias the ones you use most. The commit history is already there, waiting for the right query.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
- CSS Cheat Sheet - May 18, 2026
- How to Set Up VSCode for Python Development - May 16, 2026
- How Using One Platform Can Simplify Order Fulfillment - May 15, 2026
