Как искать проекты на github

Поиск по GitHub: как найти репозитории, нужный код или разработчика?

Правильный поиск по GitHub поможет вам найти нужного разработчика или нужный репозиторий с кодом. GitHub — это один из тех сервисов, которы е не нужно представлять людям, хоть немного связанным с программированием. Эт о ресурс, на котором каждый программист просто обязан иметь аккаунт, потому что большинство современных компаний , прежде чем нанимать к себе разработчика , проверяют его профиль на GitHub. Если в профиле «есть что посмотреть» и на самом ресурсе программист проявлял активность, то это приносит ему много плюсов в резюме.

Н а сегодняшний день на GitHub зарегистрировано более 35 миллионов аккаунтов, поэтому поиск нужного программиста именно по этому сервису более чем оправдан. Плюс ко всем у G itHub — это огромная площадка, где разработчики размещают код своих работающих приложений, которые распространяются по свободной лицензии. То ест ь G itHub — это огромное хранилище исходников, поэтому поиск нужного кода или репозитория п о этому ресурс у т оже более чем оправдан.

Поиск кода или разработчика по GitHub

Искать разработчика или нужный код можно разными путями. Например , разработчиков можно искать на специализированных сайтах по поиску работы, таких как hh.ru. Когда нужен код, можно воспользоваться специальным форумом или попросить помощи у других программистов. Но и в том и в другом случае очень правильно будет вести поиск по GitHub, ведь это один их тех ресурсов, где сконцентрированы лучшие программистские умы.

Поиск кода или репозитория по GitHub

in:name — поиск по имени репозитория, то есть искомые слова буд у т искаться в наименовании репозиториев;
in:description — поиск по описанию репозит о ри я н а совпадение указанных слов поиска именно в описании;
in:readme — поиск по файлам README;
repo:owner/name — поиск по точному совпадению имени репозитория.

по размеру репозитория;
по количеству подписчиков;
по количеству вилок;
по количеству звезд;
по дате создания;
по дате последнего обновления;
по используемому языку программирования;
по теме;
по количеству тем;
по лицензии;
по видимости репозитория;
по наличию проблем с репозиторием;
по возможности оказать спонсорскую помощь;
и др.

Поиск разработчиков по GitHub

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

Заключение

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

С поиском кода вроде все ясно, поэтому сложностей возникнуть не должно. Тем более раз вы ищите код, то вы в не м к ак миниму м р азбираетесь. Сложнее с поиском разработчиков, потому что на GitHub очень много «пустышек», которые просто будут отнимать у вас время.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Русские Блоги

Излишне говорить, насколько важен GitHub для разработчиков! Вы можете поискать? Как вы нашли подходящие ресурсы в бескрайнем океане.

Следующий поиск направлен на поиск веб-фреймворка Swift.

Общий поиск

Открываем официальный сайт GitHub и вводим информацию в строку поиска network , Я обнаружил, что было 310 000 результатов. Я отфильтровал язык и параметры сортировки из результатов. Я обнаружил, что все еще были тысячи результатов поиска. Я не знаю, какой из них мне нужен. Это как найти иголку в стоге сена, как на картинке ниже.

расширенный расширенный поиск

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

Страница расширенного поиска показана ниже

Как открыть расширенный поиск

Я не видел его на главной странице поиска github, но есть расширенная запись под языковым фильтром на странице результатов поиска. Как показано ниже

Эффективный поиск [рекомендуется]

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

Поисковый запрос + в: квалификатор
Классификатор: поисковый запрос

Поисковый запрос в: квалификатор

Квалификатор	пример
in:file	сеть в: файл содержимое файла совпадает network
in:name	сеть в: имя склада сопоставление имени network
in:path	сеть в: соответствие пути пути network
in:desc/description	сеть в: описание склада соответствует network
in:readme	сеть в: хранилище данных README соответствует содержимому network

Использование в нескольких квалификаторах условий одновременно

Также можно изменить ключевые слова на оборотную сторону, например in:file network

Классификатор: поисковый запрос

Квалификатор	пример
language:	langauage: язык программирования Swift — это проект Swift
stars:	stars:> 1000 Количество звездочек больше 1000, что указывает на популярность
fork:	Вилка:> 500 Количество вилок больше 500
size:	size:> 3000 Если размер склада превышает 3000k, он будет больше 3M. Обратите внимание, что единица измерения k
pushed:	push:> 2019-02 Нажмите после февраля 2019 года, чтобы определить, обновлялся ли он недавно
extenson:	extension: pm совпадает с суффиксом pm файла, указывая суффикс файла

Другие похожие user: Подбирайте пользователей, org： Соответствующая организация, license: Методы сопоставления сертификатов с открытым исходным кодом обычно не используются.

Подсказки: без пробелов до и после точки с запятой в квалификаторе
Обратите внимание на следующие условия поиска:

Поиск не чувствителен к регистру
Вы можете использовать кавычки "" при поиске нескольких поисковых запросов, таких как "Сеть iOS Swift" в: readme
Только авторизованные пользователи могут искать во всех публичных репозиториях

Расположение содержимого общих квалификаторов на складе выглядит следующим образом (здесь я использую Moya в качестве ссылки):

Если я не могу вспомнить, что делать, не волнуйтесь, на странице результатов поиска есть краткое руководство для просмотра.

Пример поиска

Поиск по веб-платформе Swift

Например, я хочу найти сетевую библиотеку, написанную Swift. Если обычная поисковая сеть дает 310 000 результатов, но поиск по квалификатору дает только 12 результатов, и большинство из них соответствуют требованиям сетевой структуры, таким как отображение самых популярных Alamofire и Moya в В списке.

Поиск по квалификатору: network in:readme language:Swift stars:>10000 График результатов выглядит следующим образом:

Поиск учебных материалов Spring Boot

Например, я хочу изучить фоновую разработку java и среду загрузки Spring. я использую awesome in:name stars:>3000 spring boot in:readme Чтобы добиться этого, я хочу найти классные ресурсы, связанные с Spring Boot, с относительно высокой коллекцией. Результаты поиска показаны на рисунке ниже, степень соответствия очень высока.

Другие методы поиска

Используйте отличный + поисковый запрос

Отлично — значит потрясающе. Многие учебные пособия и руководства для начинающих содержат поиск по комбинациям слов для поиска относительно качественных результатов.

Термин поиска + термин темы

На Github много тем, поэтому вы можете найти библиотеки, связанные с темами, с помощью поиска.

Практическое занятие «Поиск open-source проекта»

Чтобы проникнуть в мир API документации, нам нужно подумать о примерах API документации в нашем портфолио. Портфолио является ключом к работе технического писателя API документации. Без портфолио, содержащего убедительные примеры, будет сложно найти работу по документации API.

Избегаем “Уловки-22”

Предположим, у нас нет опыта работы с API документацией, но мы пытаемся получить работу техписателя API документации. Работодатели будут готовы не обращать внимания на опыт, если мы сможем продемонстрировать примеры написания документации API. Но как мы получим примеры описания API без API-документации? И без примеров API документации как мы можем получить желаемую работу? Это может показаться невозможной ситуацией.

Обойти эту “Уловку-22” очень просто: создаем примеры документации API с помощью проектов с открытым исходным кодом, в которые мы внесли свой вклад. Вот где пригодится данное практическое занятие.

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

Поиск опен-сорс проекта с API

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

Поиск подходящего проекта может быть сложной задачей, но он важен для вашего портфолио и вашего успеха в проникновении в мир документации API. К счастью, почти все проекты с открытым исходным кодом используют GitHub, и GitHub предоставляет различные теги для документации и «help wanted» для привлечения добровольцев. (Задача настолько распространена, GitHub предоставляет советы по поиску проектов с открытым исходным кодом.)

Идеальный опен-сорс проект должен отвечать следующим критериям:

проект содержит API (не нативную библиотеку API или какой-либо другой инструмент разработчика, который не является API);
проект нуждается в документации API;
проект не должен быть настолько технически сложным, чтобы вы не могли его изучить. (Если вы уже знакомы с языком программирования, вы можете ориентироваться на проекты, ориентированные на этот язык.);
Проект должен быть активным, с недавними коммитами.

��‍�� Практика: Поиск проекта с необходимостью документирования API

Для поиска нужного проекта:

Открываем расширенный поиск GitHub
Скроллим экран и ищем раздел Issues Options. В поле With the labels вписываем help wanted . Это стандартный тег, который команды используют для привлечения добровольцев в свой проект (но некоторые команды, которым нужна помощь, могут его и не использовать). Скроллим вверх и замечаем, что надпись: «Требуется помощь» автоматически заполняется в поле Advanced Search.
В поле Advanced Search добавляем ключевые слова documentation и api перед тегом help wanted

Нажимаем кнопку Search и видим результат.

В полученном списке можно поискать проект REST API (а не API нативной библиотеки, такой как Java API). Есть ли проекты, которые выглядят интересными или перспективными? Если так, отлично. Если нет, добавляем ключевые слова и продолжаем искать.

Если поиск на GitHub не дал подходящих проектов, можно поискать на следующих ресурсах:

Примечание. Можно потратить много времени на поиск, оценку и участие в проекте с открытым исходным кодом. Для этого упражнения хорошо бы сосредоточиться на проекте, который выглядит только слегка интересным. Не обязательно сразу коммититься, это можно сделать в любое время.

После выбора проекта пометим следующее:

Задействован ли REST API в проекте?
Как в проекте помечены проблемы, связанные с документацией? Например, используется ли в нем ярлык «документация»?
Определяем текущее состояние документации проекта: является ли она надежной, скудной, обширной, есть она вообще?
Насколько активен проект? (Какова частота коммитов?)
Сколько участников в проекте?

Примечание: Пока не нужно связываться или взаимодействовать с командой. Мы просто собираем информацию и анализируем потребности в документации здесь.

Понимание типа API, используемого в проекте

Во время поиска проекта API, нужно понять, что существует множество различных типов API. Многие из API-интерфейсов, с которыми мы работаем, могут быть исходными библиотеками API, которые не используют веб-протоколы для выполнения запросов и ответов (как это делают API-интерфейсы REST), а скорее подключают к проекту библиотеки для конкретного языка. Если кажется, что API фокусируется на определенном языке, а документация API выглядит автоматически, скорее всего это исходная библиотека API.

С другой стороны, если документация проекта содержит основные разделы конечных точек — это API REST.

Содействие потребует навыков работы с Git

Прежде чем вносить свой вклад в опен-сорс проект, нужно понять основной процесс Git Pull request. Для понимания рабочего процесса Git возможно придется освоить инструкции Git или вот Git на русском. Но лучший способ изучения Git, это активная практика в реальном проекте.

Не будем отвлекаться сейчас на Git. Можно будет изучить его уже на практике. Пока же просто ищем проект.

Не недооценивайте свои писательские навыки

Можно подумать, что слишком рано думать о присоединении к проекту, не говоря уже о внесении вклада в проект документации API, особенно когда мы только учимся этому. Когда мы взаимодействуем с командой разработки опен-сорс проекта, можно чувствовать страх, что нет навыков программирования. Однако не стоит недооценивать нашу роль в качестве автора документации (независимо от вклада). Проекты с открытым исходным кодом частенько сильно страдают от паршивой документации.

Неполная или устаревшая документация является распространенной проблемой, наблюдаемой 93 процентами респондентов, однако 60 процентов участников говорят, что они редко или никогда не вносят свой вклад в документацию.

Также посмотрим Open source documentation is bad, but proprietary software is worse Мэтта Асаи. Мэтт выделяет результаты документации того же опроса GitHub:

93% респондентов скрежетали зубами от некачественной документации, но также признались, что практически ничего не сделали для улучшения ситуации. … Если вы считаете, что глубокая потребность в документации побудит большее количество разработчиков внести свою лепту и помочь, вы ошибаетесь: 60% разработчиков не могут потрудиться представить документацию.

Так что, да, как технические писатели, мы не исправляем ошибки в коде и не разрабатываем новые функции, но наша роль разработчика документации все еще крайне необходима и ценится. Мы — редкие птицы в лесу разработки.

Автору курса хорошо знакомо значение роли документации из его личного опыта написания документации для опен-сорс проектов. В какой-то момент, прежде чем сосредоточить свою энергию на этом курсе по API, он написал несколько руководств для документации по Jekyll. Том Джонсон добавил инструкции, которые включали много нового контента, и даже добавил раздел Tutorials.

Предполагалось, что другие разработчики будут продолжать создавать новые руководства, но они этого не делали. Разработчики, как правило, добавляют небольшие отрывки документации к страницам — предложение здесь, абзац там, обновление здесь, исправление там. Редко можно найти кого-то, кто пишет новую статью или учебник с нуля. Когда выпускается новый выпуск, часто не появляются заметки о выпуске — это просто ссылки на (загадочные) журналы проблем GitHub.

Поэтому нужно быть уверенным в ценности, которую мы можем внести в опен-сорс проект. Мы создаем необходимую документацию для проекта.

Дополнительное чтение

Дополнительные материалы к изучению:

Справочник по GitHub Pull Request доступен в разделе Процесс Pull request на GitHub

Хочу контрибьютить в опенсорс: с чего начать и как искать проекты на GitHub

Разработчица Вики Коблински поделилась в блоге рекомендациями, как начать участвовать в проектах с открытым исходным кодом. Не все решаются начать делать это, например, из-за лени или потому что большинство крупных опенсорс-проектов имеют крутые кривые обучаемости и попросту могут оттолкнуть новичка.

Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага

Основная цель открытого исходного кода — создать доступное и ценное программное обеспечение (ПО), с которым сможет работать каждый. Разработчики могут найти множество личных выгод от участия в подобных проектах. Например, отточить технические навыки, развить навыки межличностного общения и попрактиковаться в предоставлении и получении обратной связи.

Изучите культуру опенсорс-проектов

Вы решили, что хотите стать участником такого проекта, но не уверены, что у вас достаточно знаний. Вики Коблински заметила, что у успешных проектов с открытым исходным кодом — самые дружелюбные сопровождающие и сообщества. Они полны энтузиазма и активно привлекают новичков. Часто такие сообщества активны в Twitter, Slack, Discord или на другой платформе, к которой может присоединиться любой желающий и напрямую поговорить с сопровождающими проекта.

Многие крупные сообщества с открытым исходным кодом имеют собственные принципы и правила, одно из главных среди них — «не быть придурком». В целом же новичков в проект принимают очень радушно.

Найдите подходящую площадку

Один из лучших способов найти подходящий проект — посмотреть на ПО с открытым исходным кодом, которое вы уже используете. Отличными кандидатами могут быть инструменты, пакеты, фреймворки или языки, с которыми вы регулярно работаете. Чтобы узнать, является ли проект открытым, важно:

Проверить его лицензию;
Убедиться, что проект активно поддерживается;
Узнать, закрываются ли в нем пул-реквесты;
Дают ли сопровождающие обратную связь.

Если так ничего подходящего не нашлось, используйте для поиска GitHub. Автор рекомендует начать контрибьютить, опираясь на знакомые языки и фреймворки — иначе будет сложно освоить кодовую базу. Если вы уже знакомы с лучшими практиками и типовой компоновкой фреймворка, будет гораздо легче приступить к работе.

У GitHub хорошие возможности для поиска проектов с открытым исходным кодом, которые нуждаются в новых участниках. Выполняя поиск по тегам и фильтруя по языкам, которые вам лучше всего известны, можно быстро найти проекты, которым нужна помощь. Вот некоторые теги для поиска:

Внесите первый вклад

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

Начинайте с малого. Берите простые тикеты, которые имеют наименьший вклад и изменения кода. Это не только позволит постепенно познакомиться с кодовой базой, но и укрепит вашу уверенность, прежде чем вы возьметесь за более сложные задачи.

После того, как выбрали тикет, исследуйте ситуацию, прежде чем отправить свой первый пул-реквест. Вики Коблински советует прочитать документацию, код и обсуждения, связанные с тикетом, чтобы лучше понять, как справиться с проблемой. Если ничего не получается, обратитесь к сообществу и попросите совета, разъяснений или наставничества.

Как только будете уверены, что решили проблему, отправляйте пул-реквест. Найдите в проекте файл «CONTRIBUTORS.md». В нем содержится инструкция о том, как правильно отправлять пул-реквест, также на GitHub есть чек-лист с рекомендациями. Обязательно сделайте обратную ссылку на исходный тикет. Сопровождающий может запросить изменения или обсудить их перед тем, как пул-реквест будет принят, — это нормально.

Как только пул-реквест пройдет проверку сопровождающего, ваши изменения будут внесены в проект.