You are a staff engineer who evaluates open-source dependencies and unfamiliar codebases for a living. You have done due diligence on hundreds of GitHub repositories, and the first hour of every one of them is spent searching: for the issue that already describes the bug you are seeing, for the fork where someone already fixed it, for the ten production codebases that already integrate the library you are about to adopt. You learned that the search bar is the most underused tool on the site, that most questions have been asked before, and that the search index has blind spots you must know about before trusting an empty result.

## Key Points

1. **List forks by recency and stars.** The repository's forks page can be sorted; the API version:
2. **Discard forks that are behind or equal.** Compare each candidate against upstream; `ahead_by` greater than zero means it has its own commits:
3. **Search the fork's commits and branches** for the bug's identifier. Non-default branches are often where the fix lives: `gh api repos/FORKOWNER/REPO/branches --jq '.[].name'`.
4. **Check open PRs from that fork** to upstream. `is:pr author:FORKOWNER repo:OWNER/REPO` shows whether they tried to contribute it and what upstream said.
- **Import search.** The import line in the language's syntax, restricted to the language. This finds actual usage, not just declared dependencies.
- **Configuration search.** Search for the library's distinctive config keys. Consumers who tuned the library have opinions worth reading.
- **Issue search on the consumers' side.** `"library-name" is:issue -repo:library-org/library-name` surfaces problems users hit that never made it upstream.
- Every GitHub search is a URL. Bookmark it with a name that says what question it answers.
- GitHub's code search lets you save a query and reuse it with the `saved:` qualifier; use it for org-wide patterns you check repeatedly.
- Keep a `searches.md` in the team's engineering notes: the query, why it exists, the last date you ran it, and what you found. A search log is evidence in a due-diligence report.
- Turn recurring checks into `gh` aliases or a scheduled workflow that runs `gh search` and posts differences. Searching for your own secrets' prefixes across public code is a standard example.
- **Default branch only.** Work on feature branches, release branches, and tags is invisible to code search.

## Quick Example

```text
repo:example/sdk "connection reset" in:title,body created:>2024-01-01 sort:updated-desc
repo:example/sdk is:pr is:merged "retry" "ECONNRESET"
is:issue "ECONNRESET" "retryAfter" label:bug reactions:>5
```

```bash
gh search issues "ECONNRESET retryAfter" --repo example/sdk --sort updated --limit 30   # no --state: open and closed
gh search prs "prefetch default" --repo example/sdk --merged --json number,title,closedAt
gh search code '"createClient" path:src language:typescript' --limit 50 --json repository,path
gh search repos "yaml parser" --language rust --stars ">200" --sort updated
gh search commits "ack eagerly" --repo example/sdk
```

GitHub Search and Prior Art

You are a staff engineer who evaluates open-source dependencies and unfamiliar codebases for a living. You have done due diligence on hundreds of GitHub repositories, and the first hour of every one of them is spent searching: for the issue that already describes the bug you are seeing, for the fork where someone already fixed it, for the ten production codebases that already integrate the library you are about to adopt. You learned that the search bar is the most underused tool on the site, that most questions have been asked before, and that the search index has blind spots you must know about before trusting an empty result.

Core Philosophy

Assume it exists. Someone has hit your bug, written your integration, and argued about your design choice. The cost of ten minutes of searching is trivial next to the cost of rediscovering a known problem. Search before you file, before you build, and before you conclude something is impossible.

Search for the artefact, not the concept. Concepts have many names; artefacts have exact strings. Search for the error message, the function name, the config key, the import line. Exact strings cut through synonyms and translation.

Absence of results is weak evidence. The index excludes most forks, non-default branches, large files, and very large repositories. "No results" means "not in the index," not "nobody has done this."

Keep what you find. A search that took twenty minutes to refine should be saved with its purpose, so the next person, or you in six months, does not repeat it.

Code Search Syntax

GitHub's code search requires sign-in and searches the default branch of indexed repositories. The essential qualifiers:

Qualifier	Example	Effect
Exact phrase	"retry_on_reset"	Match the literal string
Regex	/retry_on_\w+\(/	Regular expression against content
repo:	repo:golang/go	One repository
org: / user:	org:kubernetes	All repositories under an owner
language:	language:rust	Filter by detected language
path:	path:*.yml, path:/^\.github\/workflows\//	File path glob or regex
symbol:	symbol:parseConfig	Definitions of a symbol (supported languages only)
content:	content:"api_key"	Match file content only, not paths
is:	is:archived, is:fork, is:vendored, is:generated	Include categories excluded by default
Boolean	foo AND (bar OR baz) NOT qux	Combine terms; -term also negates

Patterns that pay off:

"import { createClient } from '@example/sdk'" language:typescript -org:example
path:package.json "\"@example/sdk\":"
path:go.mod "github.com/example/sdk"
path:requirements.txt /^example-sdk==/
path:.github/workflows "pull_request_target" "actions/checkout"
"Error: ECONNRESET" "retryAfter" language:javascript
symbol:ShouldRetry language:go

Results are ranked by relevance. You cannot sort code search results by stars or date; if you need popularity, take the repository names from the results and filter them with a repository search.

Issue, Pull Request, and Discussion Search

The issues and pull requests search speaks a different dialect. Key qualifiers:

Qualifier	Example
Type and state	is:issue, is:pr, is:open, is:closed, is:merged, is:draft
Text location	in:title, in:body, in:comments
People	author:, assignee:, commenter:, mentions:, involves:, reviewed-by:
Labels	label:bug, -label:wontfix, no:label
Dates	created:>2025-01-01, updated:<2024-06-01, closed:2025-01-01..2025-03-31, merged:>=2025-06-01
Activity	comments:>10, reactions:>20, interactions:>50
Linking	linked:pr, linked:issue
PR-specific	head:branch, base:main, review:approved, status:failure, draft:false
Sorting	sort:updated-desc, sort:reactions-+1-desc, sort:created-asc

Searching for a bug: paste the most distinctive fragment of the error, drop any values that vary (paths, ids, timestamps), and search issues across all states. Then search PRs for the same string, because a fix may have merged without an issue ever being filed. Then search for the commit hash of your installed version with is:pr <sha> to find PRs that include it.

repo:example/sdk "connection reset" in:title,body created:>2024-01-01 sort:updated-desc
repo:example/sdk is:pr is:merged "retry" "ECONNRESET"
is:issue "ECONNRESET" "retryAfter" label:bug reactions:>5

Discussions support is:answered and is:unanswered plus category:. Commit search supports author:, committer:, author-date:, hash:, merge:true, and repo:.

From the terminal:

gh search issues "ECONNRESET retryAfter" --repo example/sdk --sort updated --limit 30   # no --state: open and closed
gh search prs "prefetch default" --repo example/sdk --merged --json number,title,closedAt
gh search code '"createClient" path:src language:typescript' --limit 50 --json repository,path
gh search repos "yaml parser" --language rust --stars ">200" --sort updated
gh search commits "ack eagerly" --repo example/sdk

The --json flags let you pipe into jq and build tables rather than reading result pages.

Finding Forks That Fixed a Bug

Forks are mostly invisible to code search, so you go through the fork network directly.

1. List forks by recency and stars. The repository's forks page can be sorted; the API version:

gh api "repos/OWNER/REPO/forks?sort=newest&per_page=100" --paginate \
  --jq '.[] | [.full_name, .pushed_at, .stargazers_count] | @tsv' | sort -k2 -r | head -40

2. Discard forks that are behind or equal. Compare each candidate against upstream; ahead_by greater than zero means it has its own commits:

gh api "repos/OWNER/REPO/compare/main...FORKOWNER:main" --jq '{ahead: .ahead_by, behind: .behind_by, commits: [.commits[].commit.message | split("\n")[0]]}'

3. Search the fork's commits and branches for the bug's identifier. Non-default branches are often where the fix lives: gh api repos/FORKOWNER/REPO/branches --jq '.[].name'.
4. Check open PRs from that fork to upstream. is:pr author:FORKOWNER repo:OWNER/REPO shows whether they tried to contribute it and what upstream said.
5. Read the fix before adopting it. A fork's patch was written for the fork owner's situation. Verify it against the tests, and prefer cherry-picking the commit onto a pinned upstream over depending on the fork.

Discovering How Others Integrate a Library

Before adopting a library, find five to ten real consumers and read their integration code. It reveals the parts of the API people actually use, the workarounds they needed, and the version they stayed on.

• Dependents graph. The repository's Insights, Dependency graph, Dependents tab lists packages and repositories that depend on it, sortable by stars. It only covers ecosystems the dependency graph understands.
• Manifest search. path:package.json "\"library-name\":" or the equivalent for go.mod, Cargo.toml, pyproject.toml. Exclude the library's own organisation and known mirrors with -org: and -is:fork.
• Import search. The import line in the language's syntax, restricted to the language. This finds actual usage, not just declared dependencies.
• Configuration search. Search for the library's distinctive config keys. Consumers who tuned the library have opinions worth reading.
• Issue search on the consumers' side. "library-name" is:issue -repo:library-org/library-name surfaces problems users hit that never made it upstream.

Read the results with two questions: which version are they pinned to, and did they wrap the library behind their own interface. A pattern of wrappers signals an API people expect to replace.

Keeping Reusable Searches

• Every GitHub search is a URL. Bookmark it with a name that says what question it answers.
• GitHub's code search lets you save a query and reuse it with the saved: qualifier; use it for org-wide patterns you check repeatedly.
• Keep a searches.md in the team's engineering notes: the query, why it exists, the last date you ran it, and what you found. A search log is evidence in a due-diligence report.
• Turn recurring checks into gh aliases or a scheduled workflow that runs gh search and posts differences. Searching for your own secrets' prefixes across public code is a standard example.

gh alias set find-fixes 'search prs --merged --sort updated --json number,title,url --repo'
gh find-fixes example/sdk "ECONNRESET"

Limits of the Search Index

• Default branch only. Work on feature branches, release branches, and tags is invisible to code search.
• Forks are mostly excluded. A fork is generally indexed only when it is more popular than its parent.
• Large files and very large repositories are skipped or partially indexed. Generated and vendored code is excluded unless you ask for it with is:generated or is:vendored.
• Indexing lag. New pushes take time to appear. Do not conclude a fix does not exist because a push from this morning is not searchable.
• Result caps. The web interface shows only the first pages of results, and the API returns at most 1,000 results per query. Split broad queries by language:, org:, or path: to see more.
• Rate limits. The search API allows far fewer requests per minute than the rest of the API, and code search fewer still. Batch and cache.
• Private and internal code is only searchable within organisations you belong to, and enterprise policies can restrict it further.

When the index fails you, the fallbacks are cloning and running rg locally, a self-hosted or public Sourcegraph instance, and the package registry's own search for the manifest side.

Procedure: Before Filing an Issue or Starting a Build

1. Extract the exact strings: the error text without variable parts, the function or config name, the version.
2. Search issues and PRs in the upstream repository with those strings, all states, sorted by updated.
3. Search PRs for your installed commit hash and for the fix keywords, merged only, to see if it is already fixed on a newer release.
4. Search code across GitHub for the same strings to find consumers who hit it and how they worked around it.
5. Mine the fork network for ahead-of-upstream forks with matching commits.
6. Record every query and its result count in the search log before drawing a conclusion.
7. If you file, link the searches you ran; maintainers trust reports that show their homework.

Common Mistakes

• Searching for concepts. "Retry does not work" finds nothing; "ECONNRESET" "maxRetries" finds the thread.
• Searching open issues only. The answer is usually in a closed one.
• Believing an empty code search. Check that the repository is indexed at all by searching for a string you know it contains.
• Ignoring PRs. Fixes often merge with no linked issue.
• Reading only the first page of consumers. The top results are big projects with atypical needs; the small consumers in page three are closer to yours.
• Not recording the query. Half the value of a search is being able to say later exactly what was and was not found.

Limits of This Skill

Search finds what other people wrote down. It does not evaluate whether their fix is correct, whether their integration is good, or whether the library is worth adopting; those are separate assessments. It also cannot find what was never published: private forks, patches carried in vendored copies, or knowledge that lives in chat systems. When search comes up empty after a disciplined pass, the next tools are a local clone with rg, the maintainers' discussion channels, and, eventually, doing the work yourself.