GitHub search syntax for recruiters and sourcers

Free-text terms, then qualifier:value pairs separated by spaces. All terms are ANDed — every additional qualifier narrows the result set, never widens it. That single fact explains most disappointing GitHub searches: three languages and a location leaves nothing.

Qualifiers are not shared across search types. topic: exists for repositories and not for users; location: exists for users and not for repositories. Choosing the search type first, and the qualifiers second, avoids most confusion.

These are the ones that earn their place. Repository search is where sourcing should start — it finds the projects where your kind of work is being done, and every project has a contributor list.

Fewer than people expect, and weaker. User search only knows what someone typed into their profile, which is why it works better as a supplement than as your main discovery path.

Commit search is the most under-used surface for sourcing, because it queries content that people generate by working rather than content they wrote about themselves.

One budget warning. Commit search draws on GitHub’s search rate limit — on the order of 30 requests a minute — not the 5,000-per-hour core limit. It is the right tool for a handful of targeted lookups and the wrong tool for a loop over a hundred candidates.

Because merged pull requests to repositories someone does not own are the clearest public evidence that a person can work inside an unfamiliar codebase — read it, follow its review process, and respond to feedback. That is most of the job, and no profile field captures it.

Numeric qualifiers accept comparisons and ranges:

• stars:>100 — greater than
• stars:>=100 — greater than or equal
• stars:<50 / stars:<=50 — less than
• stars:50..500 — a closed range
• stars:100..* and stars:*..100 — open-ended ranges

Date qualifiers take YYYY-MM-DD and the same comparison forms, and accept an optional time and timezone offset:

• pushed:>2026-01-01 — active this year
• created:2024-01-01..2025-12-31 — created in that window

pushed: is the highest-value date filter in sourcing. Contributor lists on abandoned repositories are lists of people who have moved on.

Partly, and the details differ by search type — which is the most common source of silently-wrong queries.

• Exclusion works everywhere. Prefix a qualifier with -: -language:javascript, -author:some-bot. This is the reliable negation.
• Quote multi-word values. location:"New York". Unquoted, the second word becomes a separate free-text term and quietly changes the result set.
• Boolean AND / OR / NOT are code search features, not general ones. In repository and user search, spaces already mean AND and there is no OR — run two queries and merge the results.
• Code search needs a signed-in account and has its own qualifier set (path:, symbol:, content:).

• 1,000 results per query, maximum. This is the one that catches people out: a query reporting 40,000 matches will still only ever hand you 1,000 of them. The fix is not deeper paging — it is several narrower queries (split by topic, by star band, by date window) whose results you merge.
• Two separate rate limits. Roughly 5,000 core requests an hour per token, and roughly 30 search requests a minute. Mixing them up is how a pipeline stalls at 10% of expected throughput.
• Contributor lists are truncated on huge repositories. Very large projects do not return every contributor.
• Private and enterprise work is invisible. No qualifier reaches it. Whole industries are absent from these results, which is a reason to treat GitHub as one channel rather than the channel.

GitHub adjusts search behaviour over time — treat this page as a working reference and the official documentation as authoritative if the two disagree.

Five that hold up. Each is a starting point to narrow, not a finished search.

• Active projects in a domain — language:go topic:kubernetes stars:50..2000 pushed:>2026-01-01 archived:false. The star band is deliberate: it skips the famous projects everyone else is already sourcing from.
• Outside contributors whose work was merged — repo:ORG/REPO is:pr is:merged -author:OWNER. Evidence of working in someone else’s codebase.
• People who review, not just commit — repo:ORG/REPO is:pr reviewed-by:HANDLE. Reviewing is a trust signal a project granted them.
• Recent real commits by one person — author:HANDLE merge:false author-date:>2026-01-01. Drops merge noise and stale history.
• Reverse-lookup an address — author-email:someone@example.com. Confirms which accounts an address you already hold belongs to.

For how to turn any of these into an actual shortlist — contributor mining, screening, and contact resolution — see how to find and source developers on GitHub.