Introduction

If you remember part of a commit message but not the commit hash, git log --grep is the right tool. It filters commit history by the text in the commit subject and body, which makes it useful for finding feature work, bug fixes, migration commits, or release markers.

The basic command is simple, but the useful part is knowing how to widen or narrow the search without scanning the entire log manually.

Start with git log --grep

The simplest form searches commit messages reachable from the current branch tip.

git log --grep="fix login redirect"

If Git finds matches, it prints the normal commit log output for those commits. That works well, but it is often easier to read in a compact format.

git log --grep="fix login redirect" --oneline

For everyday use, --oneline is often the best default because it shows the short hash and subject on one line.

Search Across All Branches

By default, git log only walks history reachable from the current HEAD. If the commit may live on another local branch, include --all.

git log --all --grep="database migration" --oneline

This is important in repositories with long-lived release branches, merged feature branches, or partially abandoned work. Without --all, the commit may exist in the repository but still not show up.

Case-Insensitive and Regex Searches

Commit messages are just text, so Git lets you search them with regular-expression semantics.

git log --all --grep="hotfix" --regexp-ignore-case --oneline

You can also combine multiple --grep patterns. By default, multiple patterns act like OR.

git log --all --grep="release" --grep="tagged" --oneline

If you want all patterns to match, add --all-match.

git log --all --grep="release" --grep="2026" --all-match --oneline

That is useful when a single keyword is too broad.

Narrow the Result Set Further

You can combine message search with author, date, or path filters.

1git log --all \
2  --grep="refactor" \
3  --author="Mark" \
4  --since="2026-01-01" \
5  --oneline

If you care only about commits that touched a specific file or directory, add a pathspec after --.

git log --all --grep="timeout" --oneline -- src/api/

That command says: search commit messages for timeout, but only among commits that touched src/api/.

Format the Output for Faster Triage

When you are searching rather than reading history in detail, custom formatting helps.

git log --all --grep="release" --format="%h %ad %an %s" --date=short

This prints:

• short hash
• date
• author
• subject

That is usually enough to identify the commit you want before running git show <hash>.

A Practical Workflow

A fast workflow looks like this:

1. search with git log --all --grep="keyword" --oneline
2. tighten with --author, --since, or another --grep
3. inspect the winning commit with git show <hash>

That sequence is faster than scanning a graphical history viewer for most targeted searches.

Common Pitfalls

• Forgetting --all and assuming the commit does not exist when it is simply unreachable from the current branch.
• Searching only for the exact full sentence when a smaller keyword would match more reliably.
• Expecting --grep to search file contents. It searches commit messages, not diffs or source text.
• Forgetting --all-match when multiple --grep arguments should all be required.
• Using the default verbose log format when --oneline or a custom --format would make the search result much easier to scan.

Summary

• Use git log --grep="pattern" to search commit messages.
• Add --all when the commit may live outside the current branch history.
• Use --regexp-ignore-case, multiple --grep options, and --all-match to refine the search.
• Combine message search with author, date, and path filters when needed.
• Pair the search with git show once you have the commit hash you want.