To search for issues and pull requests, use the following search qualifiers in any combination.

Tips:

  • There's a list of search syntaxes you can add to any search qualifier to further improve your results.
  • Use quotations around your multi-word search terms. For example, if you want to search for issues with the label "In progress," you'd search for label:"in progress". Search is not case sensitive.

Search issues or pull requests

By default, searching issues will return both issues and pull requests. However, you can use the type qualifier to restrict search results to just issues or pull requests.

cat type:pr
Matches pull requests with the word cat.
github commenter:defunkt type:issue
Matches issues that contain the word github, and have a comment by @defunkt.

Scope the search fields

The in qualifier limits what fields are searched. With this qualifier you can restrict the search to just the title, body, comments, or any combination of these. Without the qualifier, the title, body, and comments are searched.

warning in:title
Matches issues with warning in their title.
error in:title,body
Matches issues with error in their title or body.
shipit in:comments
Matches issues mentioning :shipit: in their comments.

Search inside public and private repositories

If you're searching across all of GitHub, it can be helpful to filter your results based on whether the repository is public or private. You can do this with is:private and is:public.

is:public
Lists all the issues and pull requests in all public repositories.
is:private cupcake
Searches for issues and pull requests that talk about cupcakes in all the private repositories that you have access to.

Search by the author of an issue or pull request

The author qualifier finds issues created by a certain user. For example:

cool author:gjtorikian
Matches issues with the word cool, created by @gjtorikian.
bootstrap in:body author:mdo
Matches issues written by @mdo that contain the word bootstrap in the body.

Search by the assignee of an issue or pull request

Much like with author, the assignee qualifier finds issues that are assigned to a certain user. For example:

assignee:vmg
Matches issues assigned to @vmg.
assignee:fjakobs repo:ajaxorg/ace
Matches issues assigned to @fjakobs within the @ajaxorg/ace repository.

Search by a mentioned user within an issue or pull request

The mentions qualifier finds issues that mention a certain user. For example:

resque mentions:defunkt
Matches issues with the word "resque" that mention @defunkt anywhere.
mentions:azakus assignee:arv
Matches issues that mention @azakus but are assigned to @arv.

Search by a commenter within an issue or pull request

The commenter qualifier finds issues that contain a comment from a certain user. For example:

commenter:lennartcl
Matches issues @lennartcl commented on.
github commenter:defunkt user:github
Matches issues in repositories owned by GitHub, that contain the word github, and have a comment by @defunkt.

Search by a user that's involved within an issue or pull request

You can use the involves qualifier for finding issues that in some way involve a certain user. The involves qualifier is just a logical OR between the author, assignee, mentions and commenter qualifiers for the same user. In other words, this qualifier finds issues that were either created by a certain user, assigned to that user, mention that user, or were commented on by that user.

involves:defunkt involves:jlord
Matches issues either @defunkt or @jlord are involved in.
NOT bootstrap in:body involves:mdo
Matches issues @mdo is involved in that do not contain the word bootstrap in the body.

Search by a team that's mentioned within an issue or pull request

For organizations and teams you belong to, you can use the team qualifier to find issues or pull requests that @mention a certain team within that organization. Replace these sample names with your organization and team name to perform a search.

team:jekyll/owners
Matches issues where the `@jekyll/owners` team is mentioned.
team:myorg/ops is:open is:pr
Matches open pull requests where the `@myorg/ops` team is mentioned.

Search based on whether an issue or pull request is open

You can choose to filter issues based on whether they're open or closed based on the state qualifier. For example:

terrible state:closed in:body
Matches closed issues with the word terrible in the body (how rude).
ie state:open mentions:fat
Matches open issues that mention @fat with the word ie.

Search by the labels on an issue

You can narrow your results by labels, using the label qualifier. Since issues can have multiple labels, you can list a separate qualifier for each issue. For example:

cat label:bug
Matches issues with the word cat that are also labelled with bug.
label:bug label:resolved
Matches issues with the labels bug and resolved.
broken in:body -label:bug label:priority
Matches issues with the word "broken" in the body, that lack the label "bug", but *do* have the label "priority".

Search by milestone on an issue or pull request

The milestone qualifier finds issues or pull requests that are a part of a milestone within a repository. For example:

milestone:"overhaul"
Matches issues and pull requests that are a part of the "overhaul" milestone.

Search by project board

You can use the project qualifier to find issues that are associated with a specific project board in a repository or organization. You must search project boards by the project board number. You can find the project board number at the end of a project board's URL.

project:github/57
Matches issues owned by GitHub that are associated with the organization's project board 57.
project:github/linguist/1
Matches issues owned by GitHub that are associated with project board 1 in the linguist repository.

Search by missing metadata on an issue or pull request

You can scope issues and pull requests to those missing certain metadata using the no qualifier. That metadata includes:

  • Labels
  • Milestones
  • Assignees
  • Projects
priority no:label
Matches issues and pull requests with the word "priority" that also don't have any labels.
sprint no:milestone type:issue
Matches issues not associated with a milestone containing the word sprint.
important no:assignee language:java type:issue
Matches issues not associated with an assignee, containing the word "important," and in Java repositories.
build no:project
Matches issues not associated with a project board, containing the word "build."

Search by the main language of a repository

You can choose to search for issues within repositories that match a certain language with the language qualifiers. For example:

language:ruby state:open
Matches open issues that are in Ruby repositories.
mentions:holman language:bash
Matches issues that mention @holman within repositories containing Bash code.

Search based on the state of an issue or pull request

The is qualifier is unique, in that it provides a more human syntax to accomplish several of the above queries. For example, you can use the is qualifier to determine if:

  • An item is open or closed.
  • An item is merged or unmerged.
  • An item is a pr or an issue.

Here are some sample queries demonstrating these properties:

bugfix is:pr is:unmerged
Matches pull requests that are unmerged with the word bugfix in them.
performance is:open is:issue
Matches open issues with the word performance in them.
error is:closed
Matches closed issues and pull requests with the word error in them.

Search based on commit status

You can filter pull requests based on the status of the commits. This is especially useful if you are using the Status API or a CI service.

language:go status:pending
Matches pull requests opened into Go repositories where the status is pending.
created:2015-05-01..2015-05-30 status:failure
Matches pull requests opened on May 2015 with a failed status.
is:open status:success finally in:body
Matches open pull requests with the word "finally" in the body with a successful status.

Search based on branch names

You can filter pull requests based on the branch they came from (the "head" branch) or the branch they are merging into (the "base" branch).

head:change is:closed is:unmerged
Matches pull requests opened from branch names containing the word `change` that are closed .
base:gh-pages
Matches pull requests that are being merged into the `gh-pages` branch.

Search based on when an issue or pull request was created or last updated

You can filter issues based on times of creation, or when they were last updated. For issue creation, you can use the created qualifier; to find out when an issue was last updated, you'll want to use the updated qualifier.

Both take a date as a parameter. Date formatting must follow the ISO8601 standard, which is YYYY-MM-DD--that's year-month-day. You may also add some optional time information, formatted as THH:MM:SS+07:00--that's hour-minutes-seconds (HH:MM:SS), followed by a UTC offset (+07:00)

Dates support greater than, less than, and range qualifiers. For example:

language:c# created:<2011-01-01 state:open
Matches open issues that were created before 2011 in repositories written in C#.
weird in:body updated:>=2013-02-01
Matches issues with the word weird in the body that were updated after February 2013.
author:puzrin created:2012-11-01..2012-12-01
Matches issues created by @puzrin created between November and December of 2012.

Search based on when a pull request was merged

You can filter pull requests based on when they were merged, using the merged qualifier.

This qualifier takes a date as its parameter. Date formatting must follow the ISO8601 standard, which is YYYY-MM-DD--that's year-month-day. You may also add some optional time information, formatted as THH:MM:SS+07:00--that's hour-minutes-seconds (HH:MM:SS), followed by a UTC offset (+07:00)

Dates support greater than, less than, and range qualifiers. For example:

language:javascript merged:<2011-01-01
Matches pull requests in JavaScript repositories that were merged before 2011.
fast in:title language:ruby merged:>=2014-05-01
Matches pull requests in Ruby with the word "fast" in the title that were merged after May 2014.

Search based on when an issue or pull request was closed

You can filter issues and pull requests based on when they were closed, using the closed qualifier.

This qualifier takes a date as its parameter. Date formatting must follow the ISO8601 standard, which is YYYY-MM-DD--that's year-month-day. You may also add some optional time information, formatted as THH:MM:SS+07:00--that's hour-minutes-seconds (HH:MM:SS), followed by a UTC offset (+07:00)

Dates support greater than, less than, and range qualifiers. For example:

silly in:body closed:<2012-10-01
Matches issues and pull requests with the word "silly" in the body that were closed before October 2012.
language:swift closed:>2014-06-11
Matches issues and pull requests in Swift that were closed after June 11, 2014.

Search by the number of comments an issue or pull request has

You can choose to qualify matched labels based on comments by adding a comments range. For example:

state:closed comments:>100
Matches closed issues with more than 100 comments.
comments:500..1000
Matches issues with comments ranging from 500 to 1,000.

Search within a user's or organization's repositories

To grab a list of issues from all repositories owned by a certain user or organization, you can use the user syntax. For getting a list of issues from a specific repository, you can use the repo syntax. For example:

user:defunkt ubuntu
Matches issues with the word ubuntu from repositories owned by @defunkt.
repo:mozilla/shumway created:<2012-03-01
Matches issues from @mozilla's shumway project that were created before March 2012.

Search by the commit SHAs within a pull request

If you know the specific SHA hash of a commit, you can use it to search for pull requests that contain that SHA. Note that the SHA syntax must be at least seven characters. For example:

e1109ab
Matches pull requests with a commit SHA that starts with `e1109ab`.
0eff326d6213c is:merged
Matches merged pull requests with a commit SHA that starts with `0eff326d6213c`.

Search pull requests by review status

You can filter pull requests based on their review status (none, required, approved, changes requested, or required), by reviewer, and by requested reviewer. For example:

type:pr review:none
Matches pull requests that have not been reviewed.
type:pr review:required
Matches pull requests that require a review before they can be merged.
type:pr review:approved
Matches pull requests that a reviewer has approved.
type:pr review:changes_requested
Matches pull requests in which a reviewer has asked for changes.
type:pr reviewed-by:gjtorikian
Matches pull requests reviewed by a particular person.
type:pr review-requested:benbalter
Matches pull requests a particular person has been asked to review. Requested reviewers are no longer listed in the search results after they review a pull request.

Sort the results

With any of the qualifiers above, you can also choose to sort on these properties:

  • Number of comments
  • Date created
  • Date of last update

These can be in ascending or descending order.