Как найти код на гитхабе

Уровень сложности
Простой

Время на прочтение
11 мин

Количество просмотров 6.8K

От запуска ознакомительной версии нового улучшенного поиска кода год назад до публичной беты, которую мы выпустили на GitHub Universe в прошлом ноябре, появилась масса инноваций и резких изменений в некоторых основных продуктах GitHub, затрагивающих то, как мы, разработчики, осознаём, читаем код и ориентируемся в нем.

Нам часто задают вопрос о новом поиске по коду: «Как он работает?». В дополнение к моей лекции на GitHub Universe, я в общих чертах отвечу на этот вопрос, а также немного расскажу о системной архитектуре и технических основах данного продукта.

Так как же он работает? Мы создали собственный поисковый движок с нуля на Rust специально для поиска по коду. Наш поисковый движок называется «Blackbird», но прежде чем я стану описывать как он работает, думаю, что нужно понять наши предпосылки. На первый взгляд, создание поискового движка с нуля выглядит спорно. Зачем это делать? Разве уже нет большого количества существующих решений с открытым исходным кодом?

Если честно, на протяжении практически всей истории существования GitHub мы пытались и продолжаем пытаться использовать существующие решения данной проблемы. О нашей работе подробнее говорится в посте Павла Августинова «Краткая история поиска по коду в GitHub», но хотелось бы кое-что подчеркнуть: нам не очень везло с использованием текстового поиска для поддержки поиска по коду. Пользовательский опыт был неудовлетворительным, индексация — медленной, а хостинг — дорогим. Существует ряд новых опенсорсных проектов, нацеленных на код, но в масштабах GitHub такие проекты работать точно не будут. Поэтому мы хотели создать собственное решение:

1. У нас была мечта о полностью новом пользовательском опыте. Пользователи должны были получить возможность задавать вопросы о коде и получать ответы с помощью итеративного поиска, просмотра, навигации и чтения кода.
2. Мы понимаем, что поиск по коду однозначно отличается от текстового поиска. Код пишется для понимания машинами, а мы должны быть в состоянии воспользоваться преимуществами этой структуры и релевантности. К поиску по коду также предъявляется ряд уникальных требований: нужно искать знаки препинания (к примеру, точку или открытую скобку), выделение корней не требуется, не нужно, чтобы стоп-слова удалялись из запросов, поиск идёт с использованием регулярных выражений.
3. Масштаб GitHub делает эту задачу по-настоящему сложной. При первом развёртывании Elasticsearch индексирование всего кода на GitHub (тогда — около 8 миллионов репозиториев) заняло месяцы. Сейчас репозиториев более 200 миллионов, и код в них не неизменен: он постоянно меняется, и с этим поисковым движкам достаточно сложно справиться. В бета-версии доступен поиск по почти 45 миллионам репозиториев, в которых находится 115 Тб кода и 15,5 миллиардов файлов.

Ни одно из имеющихся решений нам не подходило, так что мы построили своё решение с нуля.

Просто используйте grep?

Для начала, давайте рассмотрим грубый метод решения проблемы. Нам часто задают этот вопрос: «Почему бы вам просто не использовать grep?». Чтобы ответить на него, давайте быстренько произведём расчёты для наших 115 Тб данных при помощи ripgrep. На компьютере с восьмиядерным процессором Intel ripgrep может выполнить исчерпывающий запрос с регулярным выражением к тринадцатигигабайтному файлу, кешированному в памяти, за 2,769 секунд или примерно за 0,6 Гб/сек/ядро.

Довольно быстро становится понятно, что такой подход не будет работать при больших объёмах данных. Поиск по коду работает на 64-ядерных кластерах из 32 машин. Даже если нам удастся разместить 115 Тб кода в памяти и безупречно распараллелить работу, потребуется занять 2048 процессорных ядер на протяжении 96 секунд для обработки одного запроса! Выполняться может только один запрос. Всем остальным придётся ждать в очереди. В результате получается 0,01 запросов в секунду (QPS) и удачи в удвоении QPS — забавно будет послушать, как вы объясняете своему начальству счета за инфраструктуру.

Разумного по цене способа масштабировать такой подход для использования со всем кодом и со всеми пользователями на GitHub просто не существует. Даже если выкинуть кучу денег на решение этой проблемы, нужного пользовательского опыта добиться всё равно не получится.

Вы уже понимаете, куда это ведёт: нужно создать индекс.

Поисковый индекс — основы

Быстро создавать запросы можно только если осуществляется предварительный расчёт информации в виде индексов. Можете считать их чем-то вроде сопоставления ключей с отсортированными списками идентификаторов документов, где находится этот ключ. Возьмём для примера небольшой индекс языков программирования. Сканируется каждый файл для определения того, на каком языке программирования он написан, файлу присваивается идентификатор, а затем создаётся инвертированный индекс, где язык является ключом, а список идентификаторов документов — значением.

Прямой индекс

Инвертированный индекс

Для поиска по коду нужен особый вид инвертированного индекса под названием n-граммный индекс. Он хорошо ищет подстроки в содержимом. N-грамма — это последовательность из n элементов. К примеру, если мы возьмём n=3 (триграммы), n-граммы, составляющие «limits» — это lim, imi, mit, its. В приведённых выше документах, индекс для этих триграмм выглядел бы следующим образом:

Для осуществления поиска мы скрещиваем результаты нескольких поисков и получаем список документов, где есть конкретная строка. С триграммным индексом необходимо четыре поиска lim, imi, mit и its для выполнения запроса limits.

В отличие от хэш-карты, эти индексы слишком велики, чтобы поместиться в память, так что взамен мы создаём итераторы для каждого индекса, к которому нужно получить доступ. Они возвращают отсортированные идентификаторы документов (идентификаторы присваиваются на основе ранжирования каждого документа) и мы скрещиваем и объединяем итераторы (как требует определённый запрос) и производим чтение настолько, чтобы получить запрошенное число результатов.

Индексируем 45 миллионов репозиториев

Следующий вопрос, который необходимо решить — создание такого индекса за разумное время (как вы помните, в первый раз это заняло месяцы). Как это часто бывает, сложность заключается в применении идей к данным, с которыми мы работаем. В нашем случае особенности две: использование контентно-адресуемого хеширования в Git и наличие большое количества дублирующихся данных на Github. Эти особенности привели нас к следующим решениям:

1. Шард через идентификатор объекта Blob, при помощи которого можно равномерно распределить документы между шардами, при этом избегая дублирования. Горячих серверов не будет из-за специальных репозиториев, а число шардов при необходимости легко масштабируется.
2. Модель индекса как дерева и использование дельта-кодирования для снижения частоты краулинга и оптимизации метаданных в индексе. Здесь метаданные — это, к примеру, список мест, где находится файл (путь, ветка и репозиторий) и информация об этих объектах (имя репозитория, владелец, видимость и т. д.). Объём таких данных для популярного контента может быть весьма большим.

Мы также создали систему, которая обеспечивает согласованность результатов запросов на уровне коммитов. Если вы ищете в репозитории, пока ваш коллега пушит код, результаты поиска не должны включать файлы из нового коммита, пока он полностью не будет обработан системой. В действительности, пока вы получаете результат запроса к репозиторию, кто-то другой может просматривать глобальные результаты и искать иное, предыдущее, но всё ещё согласованное состояние индекса. С другими поисковыми движками добиться такого поведения непросто. Устройство Blackbird позволяет работать на таком уровне согласованности запросов.

Давайте создадим индекс

Вооружившись этими идеями, давайте рассмотрим построение индекса с помощью Blackbird. На этой схеме отображена высокоуровневая общая картина обработки и индексирования в системе.

Kafka сообщает о событиях, которые говорят о необходимости что-то проиндексировать. Существует множество краулеров, взаимодействующих с Git и сервисом для извлечения символов из кода. Затем, чтобы каждый шард обрабатывал файлы для индексирования в своём ритме, снова используется Kafka.

Хотя система обычно просто отвечает на события, такие, как git push, для краулинга изменившегося содержимого необходимо проделать определённую работу для обработки всех репозиториев в первый раз. Ключевая особенность системы — это оптимизация порядка, в котором происходит эта первичная обработка, для максимально эффективного использования дельта-кодирования. Используется новая вероятностная структура данных, представляющая сходство репозиториев и определяющая порядок загрузки из обхода порядка уровней минимального остовного дерева графа сходства репозиториев^[1].

Используя оптимизированный порядок обработки, каждый репозиторий краулится путём сопоставления его с родителем в созданном нами дельта-дереве. Это означает, что нужно краулить только блобы, уникальные для этого репозитория, а не весь репозиторий. Краулинг включает в себя получение содержимого блоба из Git, его анализ для извлечения символов и создание файлов, которые станут вводными данными для индексирования.

Эти файлы затем публикуются в другой теме Kafka. Там мы разделяем ² данные между шардами. Каждый шард использует один раздел Kafka в топике. Индексирование отделено от краулинга при помощи Kafka. Согласованность запросов достигается упорядочиванием сообщений в Kafka.

Затем шарды индексатора получают эти файлы и создают их индексы: происходит токенизация для создания n-граммных индексов³ (для содержимого, символов и путей) и других нужных индексов (языков, владельцев, репозиториев и т. д.) перед сериализацией и сбросом на диск, когда накопится достаточно работы.

Наконец, шарды запускают сжатие для создания больших индексов из малых. Такие индексы более эффективны при запросах и их легче перемещать (к примеру, в реплику чтения или в резервные копии). Сжатие также использует k-образный алгоритм слияния для списков по баллам, так что релевантные файлы имеют более низкие идентификаторы и ленивые итераторы возвращают их первыми. При первоначальной обработке сжатие откладывается до большого прогона в конце, но затем, поскольку индекс не отстает от инкрементных изменений, мы выполняем сжатие с более коротким интервалом, ведь именно здесь обрабатывается, к примеру, удаления документа.

Жизненный цикл запроса

Теперь у нас есть индекс. Интересно отследить путь запроса в системе. Мы будем наблюдать за запросом-регулярным выражением к Rails organization, который ищет код, написанный на языке программирование Ruby: /arguments?/ org:rails lang:Ruby. Высокоуровневая архитектура запроса выглядит как-то так:

Между GitHub.com и шардами находится сервис, координирующий приём запросов пользователей и распределяющая запросы к каждому хосту в поисковом кластере. Для управления квотами и кеширования некоторых данных контроля доступа мы используем Redis.

Фронтенд принимает запрос пользователя и передаёт его в службу запросов Blackbird, где происходит запрос разбирается в абстрактное синтаксическое дерево. Затем происходит переписывание запроса, резолвинг, к примеру, языков в их канонические идентификаторы языков Linguist. Для разрешений и контекстов используются дополнительные условия. В этом случае, можно увидеть, как переписывание запроса гарантирует получение результатов из публичных репозиториев или любых доступных частных репозиториев.

And(
    Owner("rails"),
    LanguageID(326),
    Regex("arguments?"),
    Or(
        RepoIDs(...),
        PublicRepo(),
    ),
)

n параллельных запросов распределяются и отправляются: по одному к каждому шарду в поисковом кластере. Из-за стратегии разделения нужно отправлять запрос к каждому шарду в кластере.

Затем в каждом отдельном шарде запрос преобразуется для поиска информации в индексах. Здесь можно увидеть, что регулярное выражение становится сериями запросов подстрок на n-граммных индексах.

and(
  owners_iter("rails"),
  languages_iter(326),
  or(
    and(
      content_grams_iter("arg"),
      content_grams_iter("rgu"),
      content_grams_iter("gum"),
      or(
        and(
         content_grams_iter("ume"),
         content_grams_iter("ment")
        )
        content_grams_iter("uments"),
      )
    ),
    or(paths_grams_iter…)
    or(symbols_grams_iter…)
  ), 
  …
)

Если вы хотите узнать больше о том, как регулярные выражения становятся запросами подстрок, обратитесь к статье Расса Кокса о сопоставлении регулярных выражений с триграммным индексом. Мы используем другой алгоритм и динамические размеры грамм, а не триграммы (см. ниже ³). В данном случае движок использует следующие граммы: arg,rgu, gum, а затем либо ume и ment, либо 6-грамму uments.

Из каждого условия запускаются итераторы: and — это пересечение, or — объединение. В результате получается список файлов. Необходимо перепроверить каждый файл (чтобы подтвердить совпадения и определить их диапазоны) перед оценкой, сортировкой и возвратом запрошенного числа результатов.

В сервисе запросов мы соединяем результаты из всех шардов, заново сортируем их по оценке, фильтруем (для повторной проверки разрешений) и возвращаем топ-100. Фронтенд GitHub.com затем проводит подсветку синтаксиса и терминов, разбиение по страницам и, в конце концов, отображает результаты на странице.

Наше время отклика p99 от отдельных шардов составляет порядка 100 мс, но общее время отклика немного больше из-за соединения ответов, проверки разрешений и других факторов, таких, как подсветка синтаксиса. Запрос занимает 100 мс на одном ядре процессора на сервере индексации, поэтому верхняя граница 64-ядерных хостов составляет примерно 640 запросов в секунду. По сравнению с grep (0,01 QPS) это невероятно быстро. Система масштабируется. Возможно осуществление большого числа одновременных пользовательских запросов.

Заключение

После рассмотрения работы системы целиком, давайте снова обратимся к масштабу задачи. Пайплайн обработки может публиковать около 120 000 файлов в секунду, так что проход через все 15,5 миллиардов файлов займёт около 36 часов. Но дельта-индексирования сокращает число файлов, которые необходимо краулить, более, чем на 50%, что позволяет нам снова проиндексировать весь объём данных примерно за 18 часов.

Также мы добились значительного уменьшения размера индекса. Напомню, что сначала у нас было 115 Тб контента. Устранение дублей в контенте и дельта-индексирование позволило снизить размер примерно до 28 Тб уникального контента. А сам индекс занимает всего 25 Тб, и сюда включены не только все индексы (в том числе и n-граммы), но также и сжатая копия всего уникального контента. Это означает, что общий размер индекса и контента составляет около четверти размера исходных данных!

Если вы ещё не участвуйте в бета-тестировании, обязательно записывайтесь и попробуйте новый поиск по коду. Расскажите нам о своих ощущениях! Мы постоянно добавляем новые репозитории и устраняем недостатки, основываясь на обратной связи от пользователей — таких, как вы.

Примечания

1. Чтобы определить оптимальный порядок загрузки, нам нужен способ сказать, насколько один репозиторий похож на другой (с точки зрения их содержимого), поэтому мы изобрели новую вероятностную структуру данных, чтобы определять подобие в том же классе структур данных, что MinHash и HyperLogLog. Эта структура данных, которую мы называем геометрическим фильтром, позволяет вычислять сходство множеств и симметричную разницу между множествами с логарифмическим пространством. В этом случае множества, которые мы сравниваем, представляют собой содержимое каждого репозитория в кортежах (path, blob_sha). Вооружившись этими знаниями, мы можем построить граф, в котором вершины являются репозиториями, а ребра взвешены с помощью этой метрики сходства. Вычисление минимального остовного дерева этого графа (со сходством в качестве стоимости графа), а затем выполнение обхода дерева в порядке уровней дает нам порядок приема, в котором мы можем наилучшим образом применить дельта-кодирование. На самом деле этот граф огромен (миллионы узлов, триллионы ребер), поэтому наш алгоритм MST вычисляет приближение, это вычисление занимает всего несколько минут и дает 90% преимуществ дельта-сжатия, к которым мы стремимся.

2. Индекс сегментируется Git blob SHA. Шардинг означает распределение проиндексированных данных по нескольким серверам; его нужно выполнить, чтобы легко масштабироваться горизонтально для чтения (интересует количество запросов в секунду), для хранения (где основное внимание уделяется дисковому пространству) и для времени индексирования, ограниченного ЦП и памятью на отдельных хостах).

3. Используемые нами индексы ngram особенно интересны. Триграммы — лакомый кусочек в смысле архитектуры; как заметил Расс Кокс и другие: биграммы недостаточно избирательны, а квадрограммы занимают слишком много места; но триграммы вызывают некоторые проблемы в нашем масштабе.

Для обычных грамм, вроде for, триграммы недостаточно избирательны. Мы получаем слишком много ложных срабатываний, а это означает медленные запросы. Пример ложного срабатывания — это что-то вроде поиска документа, в котором есть каждая отдельная триграмма, но не рядом друг с другом. Вы не сможете понять, что оно ложное, пока не получите содержимое документа и дважды не проверите, в какой момент проделали большую работу, от которой нужно отказаться. Мы попробовали ряд стратегий, чтобы исправить это, например, добавление масок следования, которые для символа (в основном на полпути к квадрограммам) после триграммы используют битовые маски, но они слишком быстро насыщаются, чтобы быть полезными.

Мы называем решение «разреженными граммами», и оно работает следующим образом. Предположим, у вас есть некоторая функция, которая при задании биграммы дает вес. Пример — строка chester. Каждому биграмму присваиваем вес: 9 для «ch», 6 для «he», 3 для «es» и так далее.

А полезная теория и ещё больше практики с погружением в среду IT ждут вас на курсах SkillFactory:

• Профессия Data Scientist (24 месяца)
• Профессия Fullstack-разработчик на Python (16 месяцев)

Update May 2023:

The new code search and code view is now generally available (May. 2023)

At GitHub Universe last year, we announced a total redesign of GitHub’s code search and navigation experience, powered by our all-new code search engine that we built from scratch.
And in February, we announced our public beta.

Today, we are rolling out this feature to all GitHub users.

Check out our blog post to learn more about how GitHub’s new code search and code view can help you search, navigate, and understand your code.
And if you have feedback, please share it with us in our feedback discussion.

---

Update Dec. 2021: search has been improved again, with Search for an exact string, with support for substring matches and special characters, or regexps.

But only on cs.github.com, and still in beta (waitlist applies)

---

Update January 2013: a brand new search has arrived!, based on elasticsearch.org:

A search for stat within the ruby repo will be expressed as stat repo:ruby/ruby, and will now just work^TM.
(the repo name is not case sensitive: test repo:wordpress/wordpress returns the same as test repo:Wordpress/Wordpress)

Will give:

And you have many other examples of search, based on followers, or on forks, or…

---

Update July 2012 (old days of Lucene search and poor code indexing, combined with broken GUI, kept here for archive):

The search (based on SolrQuerySyntax) is now more permissive and the dreaded «Invalid search query. Try quoting it.» is gone when using the default search selector «Everything»:)

(I suppose we can all than Tim Pease, which had in one of his objectives «hacking on improved search experiences for all GitHub properties», and I did mention this Stack Overflow question at the time )

Here is an illustration of a grep within the ruby code: it will looks for repos and users, but also for what I wanted to search in the first place: the code!

---

Initial answer and illustration of the former issue (Sept. 2012 => March 2012)

You can use the advanced search GitHub form:

• Choose Code, Repositories or Users from the drop-down and
• use the corresponding prefixes listed for that search type.

For instance, Use the repo:username/repo-name directive to limit the search to a code repository.
The initial «Advanced Search» page includes the section:

Code Search:

The Code search will look through all of the code publicly hosted on GitHub. You can also filter by :

• the language language:
• the repository name (including the username) repo:
• the file path path:

So if you select the «Code» search selector, then your query grepping for a text within a repo will work:

---

What is incredibly unhelpful from GitHub is that:

• if you forget to put the right search selector (here «Code«), you will get an error message:
  «Invalid search query. Try quoting it.«

• the error message doesn’t help you at all.
  No amount of «quoting it» will get you out of this error.

• once you get that error message, you don’t get the sections reminding you of the right association between the search selectors («Repositories«, «Users» or «Language«) and the (right) search filters (here «repo:«).
  Any further attempt you do won’t display those associations (selectors-filters) back. Only the error message you see above…
  The only way to get back those arrays is by clicking the «Advance Search» icon:

• the «Everything» search selector, which is the default, is actually the wrong one for all of the search filters! Except «language:«…
  (You could imagine/assume that «Everything» would help you to pick whatever search selector actually works with the search filter «repo:«, but nope. That would be too easy)

• you cannot specify the search selector you want through the «Advance Search» field alone!
  (but you can for «language:«, even though «Search Language» is another combo box just below the «Search for» ‘type’ one…)

---

So, the user’s experience usually is as follows:

• you click «Advanced Search«, glance over those sections of filters, and notice one you want to use: «repo:«
• you make a first advanced search «repo:jruby/jruby stat«, but with the default Search selector «Everything«
  => FAIL! (and the arrays displaying the association «Selectors-Filters» is gone)
• you notice that «Search for» selector thingy, select the first choice «Repositories» («Dah! I want to search within repositories…»)
  => FAIL!
• dejected, you select the next choice of selectors (here, «Users«), without even looking at said selector, just to give it one more try…
  => FAIL!
• «Screw this, GitHub search is broken! I’m outta here!»
  …
  ^{(GitHub advanced search is actually not broken. Only their GUI is…)}

---

So, to recap, if you want to «grep for something inside a Github project’s code», as the OP Ben Humphreys, don’t forget to select the «Code» search selector…

Searching through code on Github

Github has just released the first preview version of its new search engine to look up code in your repositories. It’s called “Github Code Search” and provides a fuzzy-like search experience for your content on Github repositories. It crawls the repos and returns results that show the matching code lines.

As I noted, the service is currently in preview. I’m lucky to be one of the testers, but at the time of reading this article, Github Code Search might already be available to the general public.

Finding code among repos

The most basic yet also most powerful feature of Github Code Search is that you can just provide a query string and the engine will show you the relevant matches among all public repositories. Yes, you’ve read that correctly: the search returns results from not only your repositories, but all public ones by default.

All you have to do is enter the search parameter and hit enter on your keyboard. The next view will render all matches.

Of course, you can limit the search to only inspect your account’s content. This can either be done by using the prefix “owner:” to your query or by selecting your account from the left dropdown button in the search bar.

If you define the scope via the dropdown button to your account, the results get also rendered inline as a list, which is really nice for doing quick searches without changing the page.

Github’s custom query language

A more advanced feature of Github Code Search is the ability to precisely define the scope of the search via regular expressions, file paths as well as boolean operators. All together they allow you to write queries in a simple but quite efficient language.

As this is only the first iteration of the service, I’m sure Github Code Search will become much more powerful in the future. After using it for some time during the preview phase I can already say that it will be one of the most used features on Github.

I also think that Github Code Search can evolve into a competitor to Stack Overflow when it comes to searching for code snippets or templates — a feature that might already be covered by Github Copilot.

When I was a beginner to open-source contributions, one of my greatest challenge was finding the correct projects/issues to work on.

For the longest time I relied on resources curated by different writers on the internet (which were good, by the way). But I always wanted to find a way around this problem – a way I could search for and track projects that were right for my skill set.

Let’s agree on one thing: unlike Google, searching GitHub is not easy. But as a developer, chances are that you’ll interacting with GitHub or Gitlab on a daily basis.

Now the question isn’t what you use these version control systems for, but how you are using them. Just like mastering Google search skills is essential for any regular internet user, I believe it’s also essential for developers to learn how to effectively search GitHub.

In this article we are going to take a look at different techniques you can use to correctly search GitHub. You’ll learn how to search through:

• Issues and Pull Requests
• Repositories
• Users
• Topics

And more. Let’s get started.

GitHub Search Queries

In order to find detailed information about something on the internet, you need to have the correct searching skills. It’s not any different with GitHub – to find detailed info you can utilize common filter, sort, and searching techniques to easily find specific issues and pull requests of a given project.

Even though you have multiple resources listed on the internet for different projects, the main problem comes in when you want to do a search by yourself. How do you get started? Which keywords should you use to find the correct results?

Most maintainers tend to label their projects with issues, which makes it easier for contributors to find suitable projects. Listed below are some of the tricks that might help you out when you are using GitHub.

How to Search Issues and Pull Requests on GitHub

One of the most common ways of finding projects to contribute to is by searching through issues and related PRs. Here are some tricks you can use to easily find reliable answers:

1. is:issue is:open label:beginner — This particular query will list all projects with issues that are open and labeled beginner.
2. is:issue is:open label:easy — This will list all open issues that are labeled easy.
3. is:issue is:open label:first-timers-only — This lists all open issues that welcome first-timer contributions.
4. is:issue is:open label:good-first-bug — This lists projects with open issues labeled good-first-bug, to attract contributors to work on them.
5. is:issue is:open label:»good first issue» — This will list all open issues with the label good first issue, meaning it is good for place for beginners to get started.
6. is:issue is:open label:starter — This lists all open issues from across GitHub that are labeled starter.
7. is:issue is:open label:up-for-grabs — This lists open issues that are ready to be worked on if you have the necessary skills.
8. no:project type:issue is:open — This will list all open issues that are not assigned to a specific project.
9. no:milestone type:issue is:open — Many times, projects are tracked with milestones. But if you want to find issues that are not tracked, this search query will list those projects for you.
10. no:label type:issue is:open — This lists all open issues that are not labeled.
11. is:issue is:open no:assignee — This shows all open issues that have not yet been assigned to a person.

How to Search Repositories

By default, to make a search you will type the repository name in the search bar and voilà! You get some search results.

But the chances of you landing on the exact repo you intended are very low.

Let’s look at some ways you can narrow down your search:

How to Find by Name, Description/README

A thing to note when you search by Name and description of the README file is that your search phrase should begin with the in qualifier. This makes it possible to search «inside» what you are looking for.

Example

• Using in:name. Let’s say you are looking for resources to learn more about Data Science. In this case, you can use the command Data Science in:name which will list repositories with Data Science in the repository name.

• Using in:description. If you want to find repositories with a ceratin description, for example repositories where the term «freeCodeCamp» is included in the descriptionm, our search will be: freecodecamp in:description

• Using in:readme. You use this to search through a README of a file for a certain phrase. If we want to find repositories where the term freecodecamp is included in the README, our search will be: freecodecamp in:readme.

• Using in:topic. You use this to find if a certain phrase or word is labeled in the topics. For example to find all repositories where freecodecamp is listed in the topic, our search will be: freecodecamp in:topic

You can also combine multiple search queries to further narrow down the search.

How to Find by Stars, Forks

You can also search for a repository based on how many stars and forks the project has. This makes it easier for you to know how popular the project is.

Examples

• Using stars:n. If you search for a repository with 1000 stars, then your search query will be stars:1000. This will list repositories with exactly 1000 stars.

• Using forks:n. This specifies the number of forks a repository should have. If you want find repositories that have less than 100 forks, your search will be: forks:<100.

The good thing is that you can always use relational operators like <, >, <=, >= & .. to help you further narrow your search.

How to Find by Language

Another cool way to search through GitHub is by language. This helps you filter out repositories to a specific language.

Example:

• Using language:LANGUAGE. For example if you want to find repositories written in PHP, your search will be: language:PHP

How to Find by Organization Name

You can also search repositories/projects that are maintained or created by a specific organization. For this you need to begin your search with the keyword org:... followed by the organization name.

For example if you search org:freecodecamp it will list repositories that match freeCodeCamp.

How to Find by Date

If you want your results based on a specific date, you can search using one of these keywords: created, updated, merged and closed. These keywords should be accompanied by date in the format YYYY-MM-DD.

Example:

• Using keyword:YYYY-MM-DD. Take an instance where we want to make a search of all repositories with the word freeCodeCamp that were created after 2022-10-01. Then our search will be: freecodecamp created:>2022-10-01

You can also use <, >, >= and <= to search for dates after, before and on the specified date. To search within a range you can use ....

How to Find by License

Licenses are very important when you are are looking for a project to contribute to. Different licenses give different rights as to what a contributor can do or can not do.

To make it easier for you to find projects with right licenses you need to have a good understanding of licenses. You can read more about them here.

Example:

• Using license:LICENSE_KEYWORD. This is a good way to search for projects with specific licenses. To search projects with the MIT license, for instance, you would do license:MIT.

How to Find by Visibility

You can also conduct your search in terms of the visibility of the repository. In this case you can either use public or private. This will match issues and PRs that are either in a public or private repository, respectively.

Examples:

• Using is:public. This will show a list of public repositories. Let’s take an isntance where we want to search all public repositories owned by freeCodCamp. Then our search will be: is:public org:freecodecamp.
• Using is:private. This query is meant to lists all private repositories under the given search query.

Conclusion

Even though we have covered many search queries here, you can always be creative to further narrow your search by combining multiple parameters together.

For additional resources and more search parameters, you can always refer to the GitHub Docs or make use of Advanced GitHub Search. These methods will always come in handy as they offer more filering options.

There are a ton of search parameters you can use to make your daily activity around GitHub easier. Hopefully this will help you use the platform more easily and effectively.

---

---

Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started