Introduction

git grep can search only the file types you care about by combining the search pattern with pathspec filters after --. This is usually the fastest way to search within tracked files of specific extensions inside a Git repository. The important part is the syntax: the pattern comes first, -- separates it from pathspecs, and the pathspecs limit which files are searched.

Search One Extension

To search only JavaScript files:

git grep "initialize" -- '*.js'

This means:

• search for the text initialize
• only consider tracked files matching *.js

The -- separator matters because it tells Git that everything after it is a path filter, not another option or part of the pattern.

Search Multiple Extensions

You can pass more than one pathspec:

git grep "TODO" -- '*.py' '*.sh'

This searches Python and shell files only.

That is often more convenient than piping through grep or find because Git already knows which files are tracked and can search them efficiently.

Restrict by Directory and Extension

You can combine directory scope with file extension filters:

git grep "UserService" -- 'src/**/*.cs'

Or:

git grep "apiVersion" -- 'deploy/*.yaml'

This is useful when the repository contains many languages and you want to narrow the search surface quickly.

Excluding Extensions

Sometimes you want to search broadly but skip certain file types.

git grep "timeout" -- ':!*.min.js' ':!*.lock' '*'

Pathspec exclusion rules are powerful, but they can be harder to read. If the intent is simply “search only these two file types,” positive inclusion patterns are usually clearer.

Search a Specific Commit or Branch

git grep can also search a revision rather than just the working tree.

git grep "legacyApi" HEAD~2 -- '*.ts'

Or:

git grep "myFunction" main -- '*.go'

This is useful for historical investigation without checking out another branch manually.

Search Line Numbers and Ignore Case

Useful flags combine naturally with extension filters:

git grep -n -i "serializer" -- '*.cs'

This gives:

• '-n line numbers'
• '-i case-insensitive search'

You can also use extended regex with -E if needed.

Why git grep Is Often Better Than Plain grep

Compared with generic filesystem search, git grep has a few practical advantages in repositories:

• it respects Git’s view of tracked content
• it is often faster on large repos
• it works naturally with revisions and branches
• it avoids searching irrelevant generated files if they are not tracked

That makes it especially useful in code review, refactoring, and incident response workflows.

Quoting Matters

Patterns like *.js should usually be quoted so the shell does not expand them before Git sees them.

Good:

git grep "foo" -- '*.js'

Riskier:

git grep "foo" -- *.js

If the shell expands the wildcard in the current directory first, the command may behave differently from what you intended.

Practical Examples

Find all references to a config key in YAML only:

git grep -n "featureFlag" -- '*.yml' '*.yaml'

Search only TypeScript source, not tests:

git grep "AuthService" -- 'src/**/*.ts' ':!*test.ts'

Search Markdown docs for a term:

git grep -n "deployment" -- '*.md'

These combinations are where git grep really earns its keep.

Common Pitfalls

The biggest mistake is forgetting the -- separator and then wondering why the file filter is ignored or misparsed. Another is failing to quote the wildcard pathspec, which lets the shell expand it too early. Developers also often overcomplicate extension filtering with external tools when git grep already supports pathspecs directly. Finally, if a file is untracked, git grep will not search it unless you choose a different tool for that job.

Summary

• Use git grep "pattern" -- '*.ext' to search by file extension.
• Pass multiple pathspecs to search several extensions at once.
• Quote wildcard patterns so Git, not the shell, interprets them.
• Combine extension filters with flags like -n, -i, and revision arguments.
• Prefer git grep over generic filesystem search when you want tracked-repo-aware results.