Github поиск по расширению файла
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Ключ --no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ --oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
Заключение
Мы рассмотрели базовые сценарии работы с системами Git и Github. Каждая приведенная выше команда имеет значительно больше ключей и соответственно возможностей. Постепенное их изучение даст вам возможность легко оберегать свои иходники и больше концентрироваться непосредственно на разработке.
Я знаю, что веб-интерфейс GitHub позволяет вам искать во всех репозиториях файлы с определенным путем (например, поиск path:/app/models/user.rb дает> 109 тыс. Результатов), но есть ли способ искать во всех репозиториях имена файлов независимо от их расположения в подкаталоге? Я пробовал использовать звездочки в path аргументе, но это не сработало.
Тем, кто проголосовал против, я совершенно не понимаю причину. Я знаю, что это не "вопрос программирования", но он кажется вопросом "инструментов программирования", и на сайте есть и другие вопросы по github. Если речь идет о качестве вопроса, я был бы признателен за дополнительную информацию или голосование за закрытие, чтобы я мог понять, о чем вы говорите.
Ли поиск user.rb in:path сделать то , что вы хотите сделать? В качестве альтернативы также есть этот поиск filename:user.rb
using in:path YOUR_FILENAME_HERE отлично работает - и, что очень важно, работает с перекрестным репозиторием, поэтому вы можете искать репозитории всей вашей организации, чтобы найти, какие репозитории содержат определенное имя файла. Ницца!
Это больше не возможно. Поисковые запросы, на которые вы ссылаетесь, возвращают следующую ошибку: «Мы не смогли выполнить этот поиск. Должен включать хотя бы одного пользователя, организацию или репозиторий»
Да, они есть . вам просто нужно войти в GitHub, чтобы он работал. Не знаю, когда они это изменили. Это общая проблема для поиска кода, а не только для этих конкретных поисков.
Жалко, что это только «путь содержит эту строку где угодно», а не как имена файлов или что-то в этом роде: |
Во вводе поиска вы можете использовать filename параметр для поиска в нескольких репозиториях, например:
Если вы ищете имя файла в определенном репозитории, вы можете просто нажать t и начать вводить имя файла (см. Сочетания клавиш GH ).
GitHub представил FileFinder в 2011 году.
Попробуйте сами: просто нажмите t в любом представлении файла или каталога репо. [1]
Итак, вы по-прежнему ограничены репозиторием.
Другой подход к Вашему вопросу:
Да, я знал об этом и должен был упомянуть об этом в своем вопросе. То есть нет возможности искать в репозиториях? Если нет, знаете ли вы, есть ли техническая причина, почему нет?
о, так ты тоже пробовал some_weird_file_Youre_looking_for.ext in:path ? Потому что это работает для меня .
нет, но я просто попробовал, path:user.rb и он дал мне только 324 результата, и все они были user.rb на высшем уровне.
@Kamiccolo, вы должны опубликовать это как ответ, потому что это точно правильный ответ! Питер Альфвин тоже должен принять это . важная часть находится в пути. Проверено, что он работает независимо от того, где находится имя файла в пути, а не только для файлов верхнего уровня.
В моем случае я хотел найти конкретное имя файла во всех репозиториях моей организации. Это можно сделать, введя это в поле поиска:
org: имя-пользователя-вашей-организации имя- файла: имя -файла
Конечно, просто введите «имя-файла: имя-файла», если вы хотите выполнить поиск по всему GitHub.
Используя Git, как я могу найти данную строку во всех файлах во всех локальных ветвях?
Особенность GitHub: возможно ли выполнить вышеуказанный поиск по всем веткам GitHub? (В моем удаленном репозитории GitHub есть несколько удаленных веток, которые в идеале мне не пришлось бы сбрасывать для этого поиска . )
Вы можете сделать это в репозитории Git:
Расширенный поиск GitHub имеет возможность поиска кода:
Поиск кода просматривает весь код, размещенный на GitHub. Вы также можете фильтровать по:
- язык: language:
- имя хранилища (включая имя пользователя): repo:
- путь к файлу: path:
Это действительно не лучший способ сделать это. Он не контролирует количество git-ссылок, которые передаются git grep . . Посмотрите на другие ответы, они намного лучше, чем этот, даже если он помечен как принятый ответ!
было бы здорово, если бы вы могли добавить пример для своих фильтров, например path: , потому что в краткой документации не ясно, где применять этот фильтр, предполагая, что он используется перед кавычками в вашем примере запроса?
Как я могу перечислить только название филиала. В настоящее время в нем перечислены все хэши, содержащие строку.
тогда вы должны использовать xargs :
Спасибо. используя ZSH, и это работало, в то время как команда @manojlds выдавала указанную вами ошибку! Но предупреждение, это может занять ОЧЕНЬ много времени для большого репо с длинной историей.
Во многих случаях git rev-list --all может возвращаться огромное количество коммитов, которые можно сканировать вечно. Если вы вместо того, чтобы искать каждый коммит по каждой ветке в своей истории репозитория, просто хотите найти все подсказки по веткам, вы можете заменить их на git show-ref --heads . Итак, всего:
Совет: вы можете записать вывод в файл для просмотра в редакторе:
git show-ref --heads перечисляет хеш и имя ссылки, поэтому он (2-я строка) будет искать дважды. так git show-ref --heads | cut -d' ' -f2 лучше, так как он будет перечислять только имена ссылок.
Я не могу поверить, сколько раз на этот вопрос задавали и отвечали, но вы единственный, кто правильно ответил.
git show-ref --heads -s выводит только хеш SHA1. Кроме того, если есть несколько веток, указывающих на один и тот же коммит, у вас будут дубликаты. Вы можете удалить их sort -u , например, git show-ref --heads -s | sort -u | xargs git grep .
Это должен быть принятый ответ. Использование строки во всех ветвях, но только для самого последнего контента, является очень распространенным случаем использования.
Есть несколько проблем с решениями, перечисленными здесь (даже приняты).
Вам не нужно перечислять все хэши, так как вы получите дубликаты. Кроме того, это занимает больше времени.
Он основан на этом, где вы можете искать строку "test -f /" по нескольким ветвям master и dev как
который так же, как
Так что здесь идет.
Это находит хэши для кончика всех локальных веток и ищет только в тех коммитах:
Если вам нужно искать и в удаленных ветках, добавьте -a :
по крайней мере, для поиска во всех ветвях должно быть: git branch -a | cut -c3- | cut -d' ' -f 1 | xargs git grep "string" или это не удастся с -> символом в списке файлов, который обозначает отношение локальных к удаленным ветвям
Я мог бы извлечь исходный код и выполнить его локально, но мне было интересно, возможно ли это через веб-интерфейс или стороннюю альтернативу.
Поиск статистики в репо ruby будет выражаться как test repo:wordpress/wordpress возвращает так же, как test repo:Wordpress/Wordpress )
И у вас есть много других примеров поиска, основанных на подписчиках , или на вилках , или .
Обновление июль 2012 г. (старые времена поиска Lucene и плохая индексация кода в сочетании с неработающим графическим интерфейсом хранятся здесь для архивирования):
Поиск (основанный на SolrQuerySyntax ) теперь более разрешающий, и страшный " Invalid search query. Try quoting it. " исчезает при использовании селектора поиска по умолчанию "Все" :)
(Я полагаю, что мы можем все, кроме Тима Пиза , который преследовал одну из своих целей - «взломать улучшенный опыт поиска для всех свойств GitHub », и я упоминал этот вопрос переполнения стека в то время;))
Вот иллюстрация grep в коде ruby: он будет искать репозитории и пользователей, а также то, что я хотел искать в первую очередь: код!
Первоначальный ответ и иллюстрация предыдущего номера (сентябрь 2012 г. => март 2012 г.)
- Выберите Code , Repositories или Users из раскрывающегося списка и
- используйте соответствующие префиксы, перечисленные для этого типа поиска .
Например, используйте repo:username/repo-name директиву, чтобы ограничить поиск хранилищем кода .
Начальная Advanced Search страница " " включает раздел:
- язык language:
- имя хранилища (включая имя пользователя) repo:
- путь к файлу path:
Поэтому, если вы выберете Code селектор поиска " ", тогда ваш запрос для текста в репо будет работать:
Что невероятно бесполезно от GitHub, так это:
Everything Селектор поиска " ", который является настройкой по умолчанию, на самом деле является неправильным для всех фильтров поиска! За исключением " language: " .
(Вы можете представить / предположить, что " Everything " поможет вам выбрать любой селектор поиска, который действительно работает с поисковым фильтром " repo: ", но нет. Это было бы слишком просто)
Вы не можете указать нужный селектор поиска только через поле " Advance Search "!
(но вы можете использовать для " language: ", хотя " Search Language " - это еще одно поле со списком чуть ниже Search for "" типа ") .
Итак, пользовательский опыт обычно выглядит следующим образом:
- Вы нажимаете « Advanced Search », просматриваете эти разделы фильтров и замечаете тот, который хотите использовать: « repo: »
- Вы делаете первый расширенный поиск " repo:jruby/jruby stat ", но с селектором поиска по умолчанию " Everything "
=> FAIL ! (и массивы, отображающие ассоциацию «Селекторы-Фильтры», исчезли ) - вы заметили, что «Поиск» селекторной штуки, выберите первый вариант » Repositories (« Да! Я хочу искать в репозиториях . »)
=> FAIL ! - отклоненный, вы выбираете следующий выбор селекторов (здесь, " Users "), даже не глядя на упомянутый селектор, просто чтобы дать ему еще одну попытку .
=> FAIL ! - «Винт это, поиск GitHub будет сломан ! Я отсюда!»
.
(Расширенный поиск GitHub на самом деле не сломан. Только их графический интерфейс . )
Итак, подведем итог: если вы хотите «найти что-то внутри кода проекта Github», как OP Ben Humphreys , не забудьте выбрать « Code » селектор поиска .
От переводчика: публикуем для вас статью Даррена Барнса, который делится своим опытом работы с GitHub. Его советы будут полезны, в первую очередь, новичкам. Возможно, и опытный кодер найдет что-то для себя.
GitHub — отличный сервис, которым пользуются пусть не все, но очень многие программисты. После того, как объем приватных репозиториев стал неограниченным, сервис привлек внимание даже тех, кто не работал с ним раньше.
Сервис разрабатывался программистами для программистов. Его создатели добавили большое количество очень удобных инструментов, которые повышают производительность. Но, к сожалению, не все разработчики об этих инструментах знают. А кто знает — не всегда использует.
Skillbox рекомендует: Двухлетний практический курс «Я — веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Быстрый поиск файлов в репозиториях
Это один из наиболее быстрых методов поиска файлов — правда, лишь тогда, когда вы знаете, что ищете. Откройте любой репозиторий и нажмите «t». Теперь вы можете искать файлы по названию, для удобства используя кнопки направления своей клавиатуры. Для открытия файла нажимаем Enter.
Pull request, предложения по изменению кода
Для pull request предусмотрена отличная функция Suggested Changes. Если внести свое предложение, то автор кода, решив принять вашу правку, может это сделать нажатием кнопки, не покидая GitHub. Для того, чтобы внести свое предложение, необходимо обернуть сниппет с кодом markdown-сниппетом и выбрать тег suggestion.
А вот как может внести предлагаемое изменение автор кода. При этом ему не требуется вручную производить изменения в файле.
Навигация как в IDE
Здесь уже требуется установка расширения Octotree для Chrome, но ничего сложного тут нет. Зато мы получаем более удобную систему навигации. Кстати, об этом расширении мы уже писали.
Особенно полезным Octotree будет, если вы изучаете масштабный проект с большим количеством вложенных директорий. Для получения метаданных используется GitHub API.
Поддерживаются и частные репозитории (инструкции по использованию — здесь). Кроме того, поддерживается GitHub Enterprise.
Переход к функции при ревью кода
Обычно ревью кода включает в себя постоянные переходы от вызовов функций к их определениям. В результате приходится постоянно скролить туда-сюда, что неудобно. Но если нажать T, то ничего скролить не нужно, сразу переходим в требуемое место.
Создание постоянной ссылки для файла
Во время просмотра файла или директории просто нажмите Y, после чего URL будет преобразован в пермалинк, который вы сможете предоставлять кому угодно, понимая, что содержимое файла не изменится.
Если же вы распространяете обычную ссылку, то после того, как файл, на который она указывает, будет перемещен, ссылка сломается.
Git blame и heatmap
При просмотре файла нажмите B — и увидите Git blame и недавно измененные строки. Инструмент показывает, кто автор изменений, также вы получаете кликабельный линк с отсылкой к полному коммиту, часть изменений которого просматриваете.
Примерно посередине вы видите цветовые отметки (вертикальная полоса). Чем ярче эта полоса, тем новее файл. То есть вы можете видеть обновленные файлы без всякого труда, не путаясь во всем многообразии.
Мощный поиск кода
GitHub индексирует практически весь код, предлагая мощный функционал поиска в индексе. Если вам нужно найти что-то в репозитории, но вы не хотите вносить изменения, то просто нажмите / и начните искать по всему репозиторию.
Если вам нужно найти элемент, содержащий несколько слов, просто оберните словосочетание в кавычки. Собственно, это стандартный метод поиска почти для всех сервисов. На GitHub можно искать по расширению файла, его размеру и другим характеристикам.
Сохраненные ответы
Если вам не хочется из раза в раз писать одно и то же в ответ на похожие комментарии, — создайте шаблон ответа. Вместо писанины теперь можно будет выбрать нужный шаблон из выпадающего меню.
Даже мышью можно не пользоваться, просто используя сочетания ctrl+/ и ctrl+1.
GitHub — отличный инструмент, со временем он становится только лучше. Разработчики сервиса создают функции, которые помогают пользователям. Есть и дополнения, созданные энтузиастами. Для оптимизации своей работы стоит познакомиться хотя бы с частью возможностей, предлагаемых GitHub.
Читайте также: