Как узнать название репозитория git
Перейти к содержимому

Как узнать название репозитория git

  • автор:

Как узнать какие есть git репозитории на устройстве?

Как узнать какие есть git репозитории на устройстве? И, желательно, как узнать в каких папках находятся эти репозитории. //Конечно есть вариант установить на Windows приложение Everything и сделать поиск «.git» по всему ПК, но это не то, что я бы хотел.

Отслеживать
задан 10 окт 2017 в 22:05
419 2 2 золотых знака 10 10 серебряных знаков 20 20 бронзовых знаков
Только так, скорее всего.
10 окт 2017 в 22:39

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Зависит от желаемого результата. Может dir .git /b/s будет достаточно?

Отслеживать
ответ дан 11 окт 2017 в 3:40
629 4 4 серебряных знака 14 14 бронзовых знаков
а как быть с голыми репозиториями, как быть с переменной окружения GIT_DIR и другими??
11 окт 2017 в 5:21

Git — очень конфигурируемая система контроля версий. Это значит, что нет простого способа детектировать, является ли произвольно выбранный каталог Git репозиторием или нет. Скорее всего, вам придётся просмотреть каждый файл в системе на предмет наличия магических сигнатур Git.

По идее такая команда, будучи запущенной в Bash, произведёт поиск файлов (по всей ФС), которые могут иметь отношение к Git.

find / -type f -exec bash -c 'head -n1 "$1" | grep -qE $'"'(^# v2 git bundle$)|(^PACK)|(^\377tOc)|(^DIRC)'" - <> \; -print 

Отслеживать
ответ дан 11 окт 2017 в 6:37
8,602 4 4 золотых знака 30 30 серебряных знаков 53 53 бронзовых знака
И давно в Windows появился grep?
12 окт 2017 в 5:51
windows? ну те, кто этим пользуется, говорят, что там есть git’овая консолька.
12 окт 2017 в 5:54

Этот скрипт ищет что угодно, но только не репозитории)) Запустил в git bash на windows i.imgur.com/iO0hDGZ.png

2.5 Основы Git — Работа с удалёнными репозиториями

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

Примечание
Удалённый репозиторий может находиться на вашем локальном компьютере.

Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.

Просмотр удалённых репозиториев

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:

$ git clone https://github.com/schacon/ticgit Cloning into 'ticgit'. remote: Reusing existing pack: 1857, done. remote: Total 1857 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done. Resolving deltas: 100% (772/772), done. Checking connectivity. done. $ cd ticgit $ git remote origin

Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

$ git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push)

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

$ cd grit $ git remote -v bakkdoor https://github.com/bakkdoor/grit (fetch) bakkdoor https://github.com/bakkdoor/grit (push) cho45 https://github.com/cho45/grit (fetch) cho45 https://github.com/cho45/grit (push) defunkt https://github.com/defunkt/grit (fetch) defunkt https://github.com/defunkt/grit (push) koke git://github.com/koke/grit.git (fetch) koke git://github.com/koke/grit.git (push) origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push)

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

Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.

Добавление удалённых репозиториев

В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :

$ git remote origin $ git remote add pb https://github.com/paulboone/ticgit $ git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push)

Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :

$ git fetch pb remote: Counting objects: 43, done. remote: Compressing objects: 100% (36/36), done. remote: Total 43 (delta 10), reused 31 (delta 5) Unpacking objects: 100% (43/43), done. From https://github.com/paulboone/ticgit * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit

Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.

Получение изменений из удалённого репозитория — Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

$ git fetch [remote-name]

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

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Примечание

Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.

Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»

Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»

Отправка изменений в удалённый репозиторий (Push)

Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:

$ git push origin master

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.

Просмотр удалённого репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:

$ git remote show origin * remote origin Fetch URL: https://github.com/schacon/ticgit Push URL: https://github.com/schacon/ticgit HEAD branch: master Remote branches: master tracked dev-branch tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master , выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :

$ git remote show origin * remote origin URL: https://github.com/my-org/complex-project Fetch URL: https://github.com/my-org/complex-project Push URL: https://github.com/my-org/complex-project HEAD branch: master Remote branches: master tracked dev-branch tracked markdown-strip tracked issue-43 new (next fetch will store in remotes/origin) issue-45 new (next fetch will store in remotes/origin) refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove) Local branches configured for 'git pull': dev-branch merges with remote dev-branch master merges with remote master Local refs configured for 'git push': dev-branch pushes to dev-branch (up to date) markdown-strip pushes to markdown-strip (up to date) master pushes to master (up to date)

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .

Удаление и переименование удалённых репозиториев

Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :

$ git remote rename pb paul $ git remote origin paul

Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .

Если по какой-то причине вы хотите удалить удалённый репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :

$ git remote remove paul $ git remote origin

При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.

32. Что такое origin?

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

Выполните
git remote show origin 
Результат
$ git remote show origin * remote origin Fetch URL: /home/alex/githowto/repositories/work Push URL: /home/alex/githowto/repositories/work HEAD branch: main Remote branches: main tracked style tracked Local branch configured for 'git pull': main merges with remote main Local ref configured for 'git push': main pushes to main (up to date) 

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

Git status: проверка репозитория

Команда git status отображает состояние рабочего каталога и раздела проиндексированных файлов. С ее помощью можно проверить индексацию изменений и увидеть файлы, которые не отслеживаются Git. Информация об истории коммитов проекта не отображается при выводе данных о состоянии. Для этого используется команда git log .

Связанные команды git

  • git tag
    • Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1).
    • Общее назначение git blame — отображение метаданных автора, связанных со строками, которые были внесены в файл при коммите. Таким образом можно проследить историю кода и выяснить, какой именно код был внесен в репозиторий, как это было сделано и по какой причине.
    • Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также проводить поиск по ней.
    Связанные материалы
    Шпаргалка по Git
    СМ. РЕШЕНИЕ
    Изучите Git с помощью Bitbucket Cloud

    Использование

    git status

    Выводит список проиндексированных и неотслеживаемых файлов, а также файлов, удаленных из индекса Git.

    Пояснения

    Команда git status относительно проста в использовании. Она показывает, какие изменения были внесены с помощью команд git add и git commit . Сообщения о состоянии также содержат инструкции по индексированию файлов либо отмене этой операции. В примере выходных данных ниже показаны три основные категории вызова git status :

    # On branch main
    # Changes to be committed:
    # (use "git reset HEAD . " to unstage)
    #
    #modified: hello.py
    #
    # Changes not staged for commit:
    # (use "git add . " to update what will be committed)
    # (use "git checkout -- . " to discard changes in working directory)
    #
    #modified: main.py
    #
    # Untracked files:
    # (use "git add . " to include in what will be committed)
    #
    #hello.pyc

    Игнорирование файлов

    Неотслеживаемые файлы обычно подразделяются на две категории: файлы, недавно добавленные в проект и пока не отправленные в качестве коммитов, либо скомпилированные бинарные файлы (например, .pyc , .obj , .exe и т. д.). Включать файлы первой категории в выходные данные git status очень полезно, в то время как файлы второй категории могут затруднить отслеживание изменений в репозитории.

    По этой причине в Git можно полностью игнорировать файлы, поместив пути к ним в специальный файл .gitignore . Каждый игнорируемый файл указывается в отдельной строке. При этом можно использовать символ * в качестве шаблона подстановки. Так, добавление следующего выражения в файл .gitignore в корневом каталоге проекта исключит скомпилированные модули Python из выходных данных git status :

    Пример

    Перед отправкой изменений рекомендуется проверить состояние репозитория. Так вы сможете убедиться, что коммит включает только нужные данные. В следующем примере показано состояние репозитория до и после индексирования и отправки снимка состояния:

    # Edit hello.py
    git status
    # hello.py is listed under "Changes not staged for commit"
    git add hello.py
    git status
    # hello.py is listed under "Changes to be committed"
    git commit
    git status
    # nothing to commit (working directory clean)

    The first status output will show the file as unstaged. The git add action will be reflected in the second git status , and the final status output will tell you that there is nothing to commit—the working directory matches the most recent commit. Some Git commands (e.g., git merge) require the working directory to be clean so that you don’t accidentally overwrite changes.

    git log

    Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также искать в ней конкретные изменения. С помощью git status можно просматривать рабочий каталог и раздел проиндексированных файлов, в то время как git log показывает только историю коммитов.

    Существует множество вариантов для настройки выходных данных команды git log: от простой фильтрации коммитов до их отображения в пользовательском формате. Ниже показаны наиболее распространенные конфигурации git log .

    Использование

    git log

    Выводит полную историю коммитов в стандартном формате. Если выходные данные занимают более одного экрана, можно выполнить прокрутку с помощью клавиши Пробел или нажать q для выхода.

    git log -n
    git log --oneline
    git log --stat

    Кроме обычных данных git log указывается, какие файлы были изменены, а также относительное число добавленных или удаленных строк в каждом из них.

    git log -p

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

    git log --author=""

    Search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

    git log --grep=""

    Search for commits with a commit message that matches <pattern> , which can be a plain string or a regular expression.

    git log ..

    Отображает только коммиты в диапазоне значений и . Эти аргументы могут быть идентификаторами коммитов, именами веток, указателями HEAD или другими ссылками на версии.

    git log

    Выводит только коммиты, содержащие указанный файл. Так можно удобно просмотреть историю конкретного файла.

    git log --graph --decorate --oneline

    Здесь содержится несколько полезных параметров: флаг —graph создает основанную на тексте диаграмму коммитов в левой части области сообщений коммитов; флаг —decorate добавляет отображаемые имена веток или теги коммитов; флаг —oneline записывает информацию о коммите в одну строку, что позволяет без труда просматривать множество коммитов сразу.

    Пояснения

    5. Проверьте статус файла.

    commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
    Author: John Smith

    Большая часть этой информации проста для понимания, но все же первую строку стоит пояснить. Строка длиной 40 знаков, следующая за элементом commit , является контрольной суммой SHA‑1 содержимого коммита. Она играет роль механизма для обеспечения целостности коммита (при нарушении целостности контрольная сумма изменится) и служит для него уникальным идентификатором. Этот идентификатор может использоваться в таких командах, как git log .. , в качестве ссылки на конкретные коммиты. Так, команда git log 3157e..5ab91 отображает данные в диапазоне между коммитами с идентификаторами 3157e и 5ab91 . Кроме контрольных сумм, на конкретные коммиты указывают имена веток (см. раздел Модуль веток) и ключевое слово HEAD , которое всегда ссылается на текущий коммит, будь то ветка или конкретный коммит. Символ ~ используется для относительных ссылок на родительский элемент коммита. Например, 3157e~1 ссылается на коммит, предшествующий коммиту 3157e , а HEAD~3 находится на 3 уровня выше текущего коммита.

    Пример

    В разделе Использование приводится множество примеров использования git log , однако следует помнить, что в одной команде можно объединить несколько параметров:

    git log --author="John Smith" -p hello.py

    Эта команда выводит данные по всем изменениям, которые Джон Смит внес в файл hello.py . Синтаксис «..» удобно использовать при сравнении веток. В следующем примере показана команда для вывода краткого обзора всех коммитов, которые включены в ветку some-feature и не включены в main .

    git log --oneline main..some-feature

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *