как искать код на github

Searching code

You can search for code on GitHub and narrow the results using these code search qualifiers in any combination.

You can search globally across all of GitHub, or scope your search to a particular repository or organization. For more information, see «About searching on GitHub.»

You can only search code using these code search qualifiers. Search qualifiers specifically for repositories, users, or commits, will not work when searching for code.

Tips:

Considerations for code search

Due to the complexity of searching code, there are some restrictions on how searches are performed:

Search by the file contents or file path

With the in qualifier you can restrict your search to the contents of the source code file, the file path, or both. When you omit this qualifier, only the file contents are searched.

Search within a user’s or organization’s repositories

To search the code in all repositories owned by a certain user or organization, you can use the user or org qualifier. To search the code in a specific repository, you can use the repo qualifier.

Search by file location

You can use the path qualifier to search for source code that appears at a specific location in a repository. Use path:/ to search for files that are located at the root level of a repository. Or specify a directory name or the path to a directory to search for files that are located within that directory or any of its subdirectories.

Search by language

You can search for code based on what language it’s written in. The language qualifier can be the language name or alias. For a full list of supported languages with their names and aliases, see the github/linguist repository.

Search by file size

You can use the size qualifier to search for source code based on the size of the file where the code exists. The size qualifier uses greater than, less than, and range qualifiers to filter results based on the byte size of the file in which the code is found.

Search by filename

The filename qualifier matches code files with a certain filename. You can also find a file in a repository using the file finder. For more information, see «Finding files on GitHub.»

Search by file extension

The extension qualifier matches code files with a certain file extension.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Источник

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

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

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

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

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

Поиск репозитория можно выполнить по следующим идентификаторам:

in:name — поиск по имени репозитория, то есть искомые слова буд у т искаться в наименовании репозиториев;

in:description — поиск по описанию репозит о ри я н а совпадение указанных слов поиска именно в описании;

in:readme — поиск по файлам README;

repo:owner/name — поиск по точному совпадению имени репозитория.

Также можно осуществить поиск нужного репозит о рия по GitHub:

по размеру репозитория;

по количеству подписчиков;

по количеству вилок;

по количеству звезд;

по дате последнего обновления;

по используемому языку программирования;

по видимости репозитория;

по наличию проблем с репозиторием;

по возможности оказать спонсорскую помощь;

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

Среди всех популярных вариантов поиска разработч и ков отметим следующие:

Поиск по ключевым словам. К примеру, если вам необходим python-разработчик, то введите в поиске слово «python».

П оиск по технологиям. Работает так же, как и с языками программирования : просто введите название необходимого фреймворка, который не является самостоятельным языком программирования.

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

Заключение

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

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

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

Источник

Как искать в github?

никак не могу понять поиск в github, как нужно им пользоваться?

Буквально вчера вводил в строку clips выбирал язык Си (C) и наткнулся на репозиторий rbclips, при этом были еще несколько проектов для доступа к среде clips (один понял что для обращения без наворотов). Сегодня смотрю нет уже в выдаче, не видно ни с Си ни с Руби селектором.

Да и не помешала бы инфа как пользоваться фильтрами, вроде там их куча, а что делают не очень понятно, чуток разобрался с size:[1000 TO 2000] допустим будет искать проекты от 1000 до 2000 килобайт, а вот path: как работает не понял. Да и другие фильтры должно быть очень полезны, допустим про квадратные скобки догнал после прочтения статьи о поиске продуктивных программистов в github.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

GitHub: Ссылка на другой JavaScript тоже в Github
Здравствуйте. Есть у меня на ГитХабе код. HTML, одна простенькая страничка. В работе этой.

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

Как пользоваться GitHub?
Настроил ГитХаб, теперь программа сохраняется в репозитории. А как к примеру сделать откат к.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Как хорошо пользоваться GitHub’ом?
Хочу создать клон репозитория в ЗАДАННОЙ папке в своей машине и управлять им. Я в.

Как выложить проект в Github?
народ кто шарит как выложить проект со студии в github? и что такое гитинг бинарников и obj файлы?

Источник

Как находить и участвовать в проектах на гитхаб?

nemyxa,
на самом деле 99.99% пушреквестов отклоняются после глубокого фейспалма мейнтейнера из-за качества кода

А то что люди не читают маны и неправильно используют софт уже даже на фейспалм не тянет

все как в одеском анекдоте в итоге

*Для уточнения, требования денег не было

sim3x, какой еще анекдот. Они просили деньги чтобы запилит этот функционал. Финансирование.

Вместе того чтобы решит проблему сообществом, они хотят финансирование, грубя говаря денег.

не сделать, а внедрить в существующий код с обратной совместимостью
не внедрить, а повысить приоритет задачи
не код, а набросок кода

Почитайте ответ на английском сами

Не кто вам не сказал слова «не сделать»
Не кто вам не сказал слова «не внедрить»

Еще раз повторю причем тут код и набросок,обратной совместимостью. Мы вообще говорим о том что они денег просили за киллер фичу и это факт.

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

На каждый баг/фичу использовать отдельный пулл-реквест, не стоит пытаться пропихнуть всю работу за один раз.

Находить проекты просто, либо на самом ГитХабе, либо в футерах делают ссылки на свои репозитории.

Источник

15 советов по работе с Github

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

Есть много признаков качественного ПО: надёжность, устойчивость, модульность, безопасность, производительность, масштабируемость, удобство в использовании, тестировании и сопровождении. И много других признаков, в зависимости от типа приложения. В этой статье я сосредоточусь на таких свойствах:

Если вы работает в open source-проекте, то наверняка хотите публиковать свой Github-проект. Git и Github полностью изменили способ разработки OSS, де-факто превратившись, соответственно, в стандартный язык версионирования и площадку для сотрудничества.

Официально предлагаемый Github’ом рабочий процесс называется github flow. Он прекрасно описан на сайте. Этого процесса, с небольшими вариациями, придерживается большинство open source-проектов.

Github Flow очень гибок в том смысле, что он не диктует вам, как нужно релизить и документировать изменения, какую стратегию слияния использовать, когда принимать pull request’ы, какие инструменты применять, каким стандартам коммитов следовать или что нужно рецензировать перед принятием pull request’а. Всё это отдано на ваше усмотрение, и правильно сделано, поскольку не существует универсальных решений, подходящих всем командам.

Дальше я приведу список рекомендаций на основе моего опыта.

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

Приоритезируйте задачи и отслеживайте прогресс с помощью Github Projects

В сентябре 2016 появилась фича Projects. Это инструмент, позволяющий создавать доски в стиле Kanban для упорядочивания, приоритезации и отслеживания работы на уровне репозитория и организации. Если у вас есть затруднения с использованием Github, настоятельно рекомендую освоить Projects для организации и обмена информацией о приоритетах проекта и текущих усилиях.

Классифицируйте задачи с помощью тегов

Github имеет превосходные возможности по фильтрации. Если вы работаете над open source-проектом, то наверняка заинтересованы в привлечении других участников, а также в том, чтобы им было удобно. Если помечать свои задачи тегами, разработчикам легче будет ориентироваться в списке, это сэкономит им время и облегчит работу над проектом.

Используйте Github-шаблоны для pull request’ов и задач

Не пожалейте времени на написание Guthub-шаблонов для pull request’ов и информирования о проблемах. Это заставит других разработчиков — или хотя бы поможет им — слать отчёты о багах и запрашивать создание фич неким стандартным способом, прикладывая всю необходимую вам информацию.

Основные советы по отчётам о багах:

Прежде чем отправлять информацию о проблеме:

Пользуйтесь командной строкой

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

Соблюдайте строгие стандарты коммит-сообщений и категоризируйте коммиты

Всегда определяйте и соблюдайте ясные стандарты написания коммит-сообщений. Вот некоторые рекомендации:

Определяйте стандарты оформления кода и конфигурируйте прекоммит-хуки

Для написания удобного в сопровождении кода очень важно определять стандарты оформления и соблюдать их в прекоммит-хуках (pre-commits hooks). Стандарты помогут поддерживать единообразие кода вне зависимости от того, кто его пишет, а также помогут принимать и сопровождать код, написанный кем-то другим.

Я рекомендую использовать Prettier и StandardJS, но это дело вкуса, существует множество других решений; к тому же, вы можете сделать что-то своё. Главное, следуйте выбранным стандартам оформления кода, это пойдёт на пользу.

typicode/husky — прекрасный инструмент для конфигурирования прекоммит-хуков.

Используйте автоматизированные тесты и проверки pull request’ов

Очень желательно автоматизировать функциональные тесты и проверки безопасности и стиля оформления кода в каждом pull request’е. Вряд ли вы захотите всё это делать вручную. Можно быстро сконфигурировать сервер непрерывной интеграции, вроде TravisCI, чтобы автоматически прогонять тематическую ветку через тесты после отправки каждого pull request’а. Также можно сконфигурировать Github, чтобы он не позволял разработчику присоединять pull request’ы, если те не прошли тесты. При сбое тестов Github покажет автору сообщение, чтобы он исправил свои pull request’ы.

Защищайте свою мастер-ветку и требуйте проводить ревизию кода

Github позволяет защищать мастер-ветку от прямых коммитов, принудительных push’ей и перебазирования. Это очень важно, когда работаешь с кем-то над проектом. Кроме того, обязательно требуйте проводить ревизию кода, прежде чем объединять его с мастер-веткой. Это задаётся во вкладке настроек каждого репозитория.

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

Сквошьте свои pull request’ы

Много споров о том, что правильно: объединять, сквошить (squash) или перебазировать. Я считаю, что лучше всего сквошить, потому что:

Семантическое версионирование, Github-теги, релизы и автоматизированные журналы изменений
Версионирование играет огромную роль, особенно в open source-проектах, многие из которых будут зависеть от вашего ПО. Семантическое версионирование всем облегчит жизнь, потому что люди, лишь посмотрев на номер версии, будут знать, когда именно были внесены критические изменения, или содержит ли версия новые фичи или исправления багов.

Учитывая шаблон MAJOR.MINOR.PATCH, увеличивайте:

Помимо изменения версии package.json, рекомендую для каждой версии генерировать git-тег.

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

Автоматизировать этот процесс поможет TravisCI.

Автоматизируйте развёртывание с помощью тег-хуков

Не обязательно использовать ветки релизов, как это предлагается в рамках Git Flow. Можно брать артефакты развёртывания из Git-тегов. Здесь описано, как с помощью TravisCI развернуть Git-теги в heroku. Это очень просто, нужно лишь для атрибута тегов задать значение true. Такое поведение можно реализовать с помощью любого другого CI-сервера.

Для среды разработки можно настроить хук, который развёртывает последний мастер-коммит. А для сред комплектов (feature environments) можно использовать и не такие долгоживующие ветки; при желании, для каждого PR-запроса вы можете предоставлять временную тестовую среду, но такой подход сложнее, да и не является обязательным.

Настройте потоковый Github-канал для чата

Очень удобный способ отслеживания активности в ваших Github-репозиториях из места, идеально подходящего для взаимодействия с командой: простой поток уведомлений в одном или нескольких чатах. К слову, в чатах вы можете делать и многое другое, в 2013-м на Github появился термин ChatOps, подробнее о нём рассказывается здесь.

Автоматизируйте обновление зависимостей

Нам приходится регулярно тратить много времени на актуализацию зависимостей. Это идеальная задача для автоматизации. Существует много инструментов, помогающих поддерживать зависимости «свежими», автоматически создавая в проекте pull request’ы с последними версиями. Эти запросы будут прогнаны через автоматизированные нерегрессионные тесты, и если пройдут успешно, то можно надеяться, что код после объединения будет работать нормально. Будьте осторожны с изменениями уровня старших версий, дважды всё проверяйте.

С помощью расширений улучшайте работу с интерфейсом Github’а

Open source-разработчики создали много полезных расширений, улучшающих работу с интерфейсом Github’а. Например:

На Kikobeats/awesome-Github есть ещё инструменты для улучшения вашего рабочего процесса.

Источник