LIBOF

Руководства по командной строке

Man » Онлайн-руководство git - подробная онлайн-документация для страницы руководства git

🌍 ☰ 
git - тупой трекер содержимого

СИНТАКСИС

git [-v | --version] [-h | --help] [-C <путь>] [-c <имя>=<значение>]
[--exec-path[=<путь>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
[--no-optional-locks] [--no-advice] [--bare] [--git-dir=<путь>]
[--work-tree=<путь>] [--namespace=<имя>] [--config-env=<имя>=<переменная_среды>]
<команда> [<аргументы>]

ОПИСАНИЕ

Git - это быстрая, масштабируемая, распределенная система контроля версий с необычайно богатым набором команд, которая предоставляет как высокоуровневые операции, так и полный доступ к внутренним компонентам.

См. gittutorial(7), чтобы начать работу, затем см. giteveryday(7), чтобы получить полезный минимальный набор команд. В Руководстве пользователя Git[1] содержится более подробное введение.

После того, как вы освоите основные понятия, вы можете вернуться на эту страницу, чтобы узнать, какие команды предлагает Git. Вы можете узнать больше об отдельных командах Git с помощью "git help command". Руководство gitcli(7) дает общее представление о синтаксисе командной строки.

Отформатированную и гипертекстовую копию последней документации Git можно найти по адресу
https://git.github.io/htmldocs/git.html или https://git-scm.com/docs.

ОПЦИИ

-v, --version

Выводит версию пакета Git, из которого была получена программа git.

Эта опция внутренне преобразуется в git version ... и принимает те же параметры, что и команда git-version(1). Если также указана опция --help, она имеет приоритет над --version.

-h, --help

Выводит краткое описание и список наиболее часто используемых команд. Если указана опция --all или -a, выводятся все доступные команды. Если указана команда Git, отображается страница руководства для этой команды.

Доступны другие параметры для управления отображением страницы руководства. См. git-help(1) для получения дополнительной информации, потому что git --help ... внутренне преобразуется в git help ....

-C <путь>

Запускает программу так, как если бы git была запущена в <путь>, а не в текущем рабочем каталоге. При указании нескольких опций -C каждая последующая неабсолютная опция -C <путь> интерпретируется относительно предыдущей опции -C <путь>. Если <путь> присутствует, но пуст, например, -C "", то текущий рабочий каталог остается неизменным.

Эта опция влияет на параметры, которые ожидают имя пути, такие как --git-dir и --work-tree, в том смысле, что их интерпретация имен путей будет осуществляться относительно рабочего каталога, созданного опцией -C. Например, следующие вызовы эквивалентны:

git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status

-c <имя>=<значение>

Передает параметр конфигурации команде. Указанное значение перезапишет значения из файлов конфигурации. Ожидается, что <имя> будет в том же формате, как указано в git config (подключи разделены точками).

Обратите внимание, что опускание знака = в git -c foo.bar ... допустимо и устанавливает для foo.bar булево значение true (так же, как и [foo]bar в файле конфигурации). Включение знака равенства, но с пустым значением (например, git -c foo.bar= ...) устанавливает для foo.bar пустую строку, которую git config --type=bool преобразует в false.

^ -config-env=<name>=<envvar> Подобно -c <name\>=<value\>, задает значение переменной конфигурации <name\>, где <envvar> — имя переменной среды, из которой нужно получить значение. В отличие от -c, здесь нет сокращенного способа установки значения в пустую строку; вместо этого сама переменная среды должна быть установлена в пустую строку. Если <envvar> не существует в среде, возникает ошибка. <envvar> не может содержать знак равенства, чтобы избежать неоднозначности с <name>, который может его содержать.

Это полезно в случаях, когда вы хотите передавать временные параметры конфигурации в Git, но при этом работаете в операционных системах, где другие процессы могут читать вашу командную строку (например, /proc/self/cmdline), но не вашу среду (например, /proc/self/environ). Такое поведение является стандартным для Linux, но может отличаться в вашей системе.

Обратите внимание, что это может повысить безопасность для переменных, таких как http.extraHeader, где конфиденциальная информация является частью значения, но не для переменных, таких как url.<base>.insteadOf, где конфиденциальная информация может быть частью ключа.

^ -exec-path[=<path>] Путь к тому месту, где установлены основные программы Git. Этим также можно управлять, установив переменную среды GIT_EXEC_PATH. Если путь не указан, Git выведет текущее значение и завершит работу.

^ -html-path Выводит путь, без завершающей косой черты, к тому месту, где установлена HTML-документация Git, и завершает работу.

^ -man-path Выводит путь поиска (manpath) для страниц руководства (man) для этой версии Git и завершает работу.

^ -info-path Выводит путь, где установлены файлы Info, содержащие документацию для этой версии Git, и завершает работу.

^ p, --paginate Передает весь вывод в программу less (или, если она установлена, в $PAGER), если стандартный вывод является терминалом. Это переопределяет параметры конфигурации pager.<cmd> (см. раздел «Механизм конфигурации» ниже).

^ P, --no-pager Не передает вывод Git в программу постраничного просмотра.

^ -git-dir=<path> Устанавливает путь к репозиторию (каталогу .git). Этим также можно управлять, установив переменную среды GIT_DIR. Это может быть абсолютный или относительный путь к текущему рабочему каталогу.

Указание расположения каталога .git с помощью этой опции (или переменной среды GIT_DIR) отключает обнаружение репозитория, которое пытается найти каталог с подкаталогом .git (чтобы определить репозиторий и верхний уровень рабочего дерева), и сообщает Git, что вы находитесь в верхнем уровне рабочего дерева. Если вы не находитесь в верхнем каталоге рабочего дерева, вам следует указать Git, где находится верхний уровень рабочего дерева, с помощью опции --work-tree=<path> (или переменной среды GIT_WORK_TREE).

Если вам нужно просто запускать git так, как будто он был запущен в <path\>, используйте git -C <path\>.

--work-tree=<path>

Устанавливает путь к рабочей области. Это может быть абсолютный путь или путь, относительный к текущему рабочему каталогу. Этим также можно управлять, установив переменную окружения GIT_WORK_TREE и переменную конфигурации core.worktree (см. core.worktree в gitconfig(1) для более подробного обсуждения).

--namespace=<path>

Устанавливает пространство имен Git. См. gitnamespaces(7) для получения дополнительной информации. Эквивалентно установке переменной окружения GIT_NAMESPACE.

--bare

Обрабатывает репозиторий как "голый" репозиторий. Если переменная окружения GIT_DIR не установлена, она устанавливается в текущий рабочий каталог.

--no-replace-objects

Не использовать заменяющие ссылки для замены объектов Git. Эквивалентно установке переменной окружения GIT_NO_REPLACE_OBJECTS с любым значением. См. git-replace(1) для получения дополнительной информации.

--no-lazy-fetch

Не выполнять извлечение отсутствующих объектов из удаленного репозитория "по требованию". Полезно в сочетании с git cat-file -e <object\>, чтобы проверить, доступен ли объект локально. Эквивалентно установке переменной окружения GIT_NO_LAZY_FETCH в 1.

--no-optional-locks

Не выполнять необязательные операции, требующие блокировок. Эквивалентно установке переменной окружения GIT_OPTIONAL_LOCKS в 0.

--no-advice

Отключает вывод всех информационных сообщений.

--literal-pathspecs

Обрабатывает спецификации путей буквально (т.е. без использования шаблонов, без магии спецификаций путей). Эквивалентно установке переменной окружения GIT_LITERAL_PATHSPECS в 1.

--glob-pathspecs

Добавляет "магию glob" ко всем спецификациям путей. Эквивалентно установке переменной окружения GIT_GLOB_PATHSPECS в 1. Отключение использования шаблонов для отдельных спецификаций путей можно выполнить с помощью магии спецификаций путей :(literal).

--noglob-pathspecs

Добавляет "магию literal" ко всем спецификациям путей. Эквивалентно установке переменной окружения GIT_NOGLOB_PATHSPECS в 1. Включение использования шаблонов для отдельных спецификаций путей можно выполнить с помощью магии спецификаций путей :(glob).

--icase-pathspecs

Добавляет "магию icase" ко всем спецификациям путей. Эквивалентно установке переменной окружения GIT_ICASE_PATHSPECS в 1.

--list-cmds=<group>[,<group>...]

Перечисляет команды по группам. Это внутренняя/экспериментальная опция и может быть изменена или удалена в будущем. Поддерживаемые группы: builtins, parseopt (встроенные команды, использующие parse-options), main (все команды в каталоге libexec), others (все остальные команды в $PATH, имеющие префикс git-), list-<category> (см. категории в command-list.txt), nohelpers (исключить вспомогательные команды), alias и config (получить список команд из переменной конфигурации completion.commands).

--attr-source=<tree-ish>

Считывает атрибуты Git из <tree-ish> вместо рабочей области. См. gitattributes(5). Эквивалентно установке переменной окружения GIT_ATTR_SOURCE.

КОМАНДЫ GIT

Мы делим Git на команды высокого уровня ("поверхностные") и команды низкого уровня ("внутренние").

КОМАНДЫ ВЫСОКОГО УРОВНЯ (PORCELAIN)

Мы разделяем команды высокого уровня на основные команды и некоторые вспомогательные утилиты для пользователя.

Основные команды высокого уровня

git-add(1)

Добавить содержимое файлов в индекс.

git-am(1)

Применить серию патчей из почтового ящика.

git-archive(1)

Создать архив файлов из указанного дерева.

git-backfill(1)

Загрузить отсутствующие объекты в частичном клоне.

git-bisect(1)

Использовать бинарный поиск для определения коммита, который внес ошибку.

git-branch(1)

Список, создание или удаление веток.

git-bundle(1)

Переместить объекты и ссылки с помощью архива.

git-checkout(1)

Переключать ветки или восстанавливать файлы рабочего дерева.

git-cherry-pick(1)

Применить изменения, внесенные существующими коммитами.

git-citool(1)

Графический альтернативный интерфейс для git-commit.

git-clean(1)

Удалить неотслеживаемые файлы из рабочего дерева.

git-clone(1)

Клонировать репозиторий в новый каталог.

git-commit(1)

Зафиксировать изменения в репозитории.

git-describe(1)

Присвоить объекту удобочитаемое имя на основе доступной ссылки.

git-diff(1)

Показать изменения между коммитами, коммитом и рабочим деревом и т. д.

git-fetch(1)

Загрузить объекты и ссылки из другого репозитория.

git-format-patch(1)

Подготовить патчи для отправки по электронной почте.

git-gc(1)

Очистить ненужные файлы и оптимизировать локальный репозиторий.

git-grep(1)

Вывести строки, соответствующие шаблону.

git-gui(1)
Портативный графический интерфейс для Git.

git-init(1)

Создать пустой репозиторий Git или повторно инициализировать существующий.

git-log(1)

Показать историю коммитов.

git-maintenance(1)

Выполнить задачи для оптимизации данных репозитория Git.

git-merge(1)

Объединить две или более истории разработки.

git-mv(1)

Переместить или переименовать файл, каталог или символическую ссылку.

git-notes(1)

Добавить или просмотреть заметки к объектам.

git-pull(1)

Получить данные из другого репозитория или локальной ветки и объединить их.

git-push(1)

Обновить удаленные ссылки вместе с соответствующими объектами.

git-range-diff(1)

Сравнить два диапазона коммитов (например, две версии ветки).

git-rebase(1)

Применить коммиты поверх другой базовой точки.

git-reset(1)

Сбросить текущий HEAD до указанного состояния.

git-restore(1)

Восстановить файлы рабочего дерева.

git-revert(1)

Отменить существующие коммиты.

git-rm(1)

Удалить файлы из рабочего дерева и из индекса.

git-shortlog(1)

Суммировать вывод git log.

git-show(1)

Показать различные типы объектов.

git-sparse-checkout(1)

Сократить рабочее дерево до подмножества отслеживаемых файлов.

git-stash(1)

Временно сохранить изменения в грязном рабочем каталоге.

git-status(1)

Показать состояние рабочего дерева.

git-submodule(1)

Инициализировать, обновить или проверить подмодули.

git-switch(1)

Переключать ветки.

git-tag(1)

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

git-worktree(1)

Управлять несколькими рабочими деревьями.

gitk(1)

Обозреватель репозитория Git.

scalar(1)
Инструмент для управления большими репозиториями Git.

Вспомогательные команды

Манипуляторы:

git-config(1)

Получить и установить параметры репозитория или глобальные параметры.

git-fast-export(1)

Экспортер данных Git.

git-fast-import(1)
Бэкенд для быстрых инструментов импорта данных в Git.

git-filter-branch(1)
Изменение веток.

git-mergetool(1)
Запуск инструментов разрешения конфликтов при слиянии для разрешения конфликтов.

git-pack-refs(1)
Упаковка головных и теговых ссылок для эффективного доступа к репозиторию.

git-prune(1)
Удаление всех недоступных объектов из базы данных объектов.

git-reflog(1)
Управление информацией журнала ссылок.

git-refs(1)
Низкоуровневый доступ к ссылкам.

git-remote(1)
Управление набором отслеживаемых репозиториев.

git-repack(1)
Упаковка распакованных объектов в репозитории.

git-replace(1)
Создание, перечисление, удаление ссылок для замены объектов.

Инструменты для анализа:

git-annotate(1)
Аннотация строк файла информацией о коммите.

git-blame(1)
Показ информации о том, какая ревизия и автор последний раз изменяли каждую строку файла.

git-bugreport(1)
Сбор информации для пользователя, чтобы он мог отправить отчет об ошибке.

git-count-objects(1)
Подсчет количества распакованных объектов и их дискового пространства.

git-diagnose(1)
Создание zip-архива диагностической информации.

git-difftool(1)
Отображение изменений с помощью распространенных инструментов сравнения.

git-fsck(1)
Проверка связности и действительности объектов в базе данных.

git-help(1)
Отображение справочной информации о Git.

git-instaweb(1)
Мгновенный просмотр рабочего репозитория в gitweb.

git-merge-tree(1)
Выполнение слияния без изменения индекса или рабочего дерева.

git-rerere(1)
Повторное использование сохраненных решений конфликтующих слияний.

git-show-branch(1)
Отображение веток и их коммитов.

git-verify-commit(1)
Проверка GPG-подписи коммитов.

git-verify-tag(1)
Проверка GPG-подписи тегов.

git-version(1)
Отображение информации о версии Git.

git-whatchanged(1)
Отображение логов с отображением изменений, вносимых каждым коммитом.

gitweb(1)
Веб-интерфейс Git (веб-интерфейс для репозиториев Git).

Взаимодействие с другими

Эти команды предназначены для взаимодействия с другими системами управления версиями и для взаимодействия с другими людьми посредством отправки патчей по электронной почте.

git-archimport(1)
Импорт репозитория GNU Arch в Git.

git-cvsexportcommit(1)
Экспорт отдельного коммита в CVS.

git-cvsimport(1)
Извлечение данных из другой системы управления версиями, которую многие любят ненавидеть.

git-cvsserver(1)
Эмулятор CVS-сервера для Git.

git-imap-send(1)
Отправка набора патчей из стандартного ввода в папку IMAP.

git-p4(1)
Импорт и отправка в репозитории Perforce.

git-quiltimport(1)
Применение набора патчей Quilt к текущей ветке.

git-request-pull(1)
Создание сводки об ожидающих изменениях.

git-send-email(1)
Отправка набора патчей по электронной почте.

git-svn(1)
Двунаправленная работа между репозиторием Subversion и Git.

Сброс, восстановление и откат

Существует три команды с похожими именами: git reset, git restore и git revert.

git-revert(1) используется для создания нового коммита, который отменяет изменения, внесенные другими коммитами.

git-restore(1) используется для восстановления файлов в рабочем дереве либо из индекса, либо из другого коммита. Эта команда не обновляет вашу ветку. Эту команду также можно использовать для восстановления файлов в индексе из другого коммита.

git-reset(1) используется для обновления вашей ветки, перемещения указателя, чтобы добавить или удалить коммиты из ветки. Эта операция изменяет историю коммитов.

git reset также можно использовать для восстановления индекса, что перекрывается с git restore.

КОМАНДЫ НИЗКОГО УРОВНЯ (ПЛУМБИНГ)

Хотя Git включает в себя собственный уровень команд, его команды низкого уровня достаточны для поддержки разработки альтернативных команд. Разработчики таких команд могут начать с изучения git-update-index(1) и git-read-tree(1).

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

Следующее описание разделяет команды низкого уровня на команды, которые манипулируют объектами (в репозитории, индексе и рабочей области), команды, которые проверяют и сравнивают объекты, и команды, которые перемещают объекты и ссылки между репозиториями.

Команды манипулирования

git-apply(1)

Применить патч к файлам и/или к индексу.

git-checkout-index(1)

Скопировать файлы из индекса в рабочую область.

git-commit-graph(1)

Записать и проверить файлы графа коммитов Git.

git-commit-tree(1)

Создать новый объект коммита.

git-hash-object(1)

Вычислить идентификатор объекта и, при необходимости, создать объект из файла.

git-index-pack(1)

Создать индексный файл пакета для существующего упакованного архива.

git-merge-file(1)

Выполнить трехстороннее слияние файлов.

git-merge-index(1)

Выполнить слияние для файлов, требующих слияния.

git-mktag(1)

Создает объект тега с дополнительной проверкой.

git-mktree(1)

Создать объект дерева из текста в формате ls-tree.

git-multi-pack-index(1)

Записать и проверить мульти-индексы пакетов.

git-pack-objects(1)

Создать упакованный архив объектов.

git-prune-packed(1)

Удалить лишние объекты, которые уже находятся в файлах пакетов.

git-read-tree(1)

Прочитать информацию о дереве в индекс.

git-replay(1)
ЭКСПЕРИМЕНТАЛЬНО: Воспроизвести коммиты на новой базе, работает также с пустыми репозиториями.

git-symbolic-ref(1)

Читать, изменять и удалять символические ссылки.

git-unpack-objects(1)

Распаковать объекты из упакованного архива.

git-update-index(1)

Зарегистрировать содержимое файлов в рабочей области в индексе.

git-update-ref(1)

Безопасно обновить имя объекта, хранящееся в ссылке.

git-write-tree(1)

Создать объект дерева из текущего индекса.

Команды проверки

git-cat-file(1)

Предоставить содержимое или сведения об объектах репозитория.

git-cherry(1)

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

git-diff-files(1)

Сравнить файлы в рабочей области и индексе.

git-diff-index(1)

Сравнить дерево с рабочей областью или индексом.

git-diff-pairs(1)

Сравнить содержимое и режим предоставленных пар блобов.

git-diff-tree(1)

Сравнить содержимое и режим блобов, найденных через два объекта дерева.

git-for-each-ref(1)

Вывести информацию о каждой ссылке.

git-for-each-repo(1)

Выполнить команду Git в списке репозиториев.

git-get-tar-commit-id(1)

Извлечь идентификатор коммита из архива, созданного с помощью git-archive.

git-ls-files(1)
Отображает информацию о файлах в индексе и в рабочей области.

git-ls-remote(1)
Выводит список ссылок в удаленном репозитории.

git-ls-tree(1)
Выводит содержимое дерева объектов.

git-merge-base(1)
Находит наилучшие общие предки для слияния.

git-name-rev(1)
Находит символические имена для заданных ревизий.

git-pack-redundant(1)
Находит избыточные файлы пакетов.

git-rev-list(1)
Выводит список объектов коммитов в обратном хронологическом порядке.

git-rev-parse(1)
Извлекает и обрабатывает параметры.

git-show-index(1)
Отображает упакованный индекс архива.

git-show-ref(1)
Выводит список ссылок в локальном репозитории.

git-unpack-file(1)
Создает временный файл с содержимым блоба.

git-var(1)
Отображает логическую переменную Git.

git-verify-pack(1)
Проверяет упакованные файлы архивов Git.

В общем, команды «интеррогации» не изменяют файлы в рабочей области.

Синхронизация репозиториев

git-daemon(1)
Очень простой сервер для репозиториев Git.

git-fetch-pack(1)
Получает отсутствующие объекты из другого репозитория.

git-http-backend(1)
Серверная реализация Git по протоколу HTTP.

git-send-pack(1)
Отправляет объекты по протоколу Git в другой репозиторий.

git-update-server-info(1)
Обновляет вспомогательный файл информации, чтобы помочь простым серверам.

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

git-http-fetch(1)
Загрузка из удаленного репозитория Git по протоколу HTTP.

git-http-push(1)
Отправка объектов по протоколу HTTP/DAV в другой репозиторий.

git-receive-pack(1)
Получает отправленные данные в репозиторий.

git-shell(1)
Ограниченная оболочка для входа в систему для доступа к Git только через SSH.

git-upload-archive(1)
Отправляет архив обратно в git-archive.

git-upload-pack(1)
Отправляет объекты в упакованном виде обратно в git-fetch-pack.

Внутренние вспомогательные команды

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

git-check-attr(1)
Отображает информацию о gitattributes.

git-check-ignore(1)
Отлаживает файлы gitignore/exclude.

git-check-mailmap(1)
Отображает канонические имена и адреса электронной почты контактов.

git-check-ref-format(1)
Гарантирует, что имя ссылки имеет правильный формат.

git-column(1)
Отображает данные в столбцах.

git-credential(1)
Извлекает и хранит учетные данные пользователя.

git-credential-cache(1)
Вспомогательная программа для временного хранения паролей в памяти.

git-credential-store(1)
Вспомогательная программа для хранения учетных данных на диске.

git-fmt-merge-msg(1)
Создает сообщение коммита слияния.

git-hook(1)
Запускает хуки Git.

git-interpret-trailers(1)
Добавляет или анализирует структурированную информацию в сообщениях коммитов.

git-mailinfo(1)
Извлекает информацию о патче и авторстве из одного сообщения электронной почты.

git-mailsplit(1)
Простая программа для разделения файлов mbox в UNIX.

git-merge-one-file(1)
Стандартная вспомогательная программа для использования с git-merge-index.

git-patch-id(1)
Вычисляет уникальный идентификатор для патча.

git-sh-i18n(1)
Код настройки i18n для скриптов оболочки Git.

git-sh-setup(1)
Общий код настройки скрипта оболочки Git.

git-stripspace(1)
Удаляет ненужные пробелы.

РУКОВОДСТВА

Следующие страницы документации содержат руководства по концепциям Git.

gitcore-tutorial(7)
Основное руководство по Git для разработчиков.

gitcredentials(7)
Предоставление имен пользователей и паролей для Git.

gitcvs-migration(7)
Git для пользователей CVS.

gitdiffcore(7)
Настройка вывода `diff`.

giteveryday(7)
Полезный минимальный набор команд для повседневной работы с Git.

gitfaq(7)
Часто задаваемые вопросы об использовании Git.

gitglossary(7)
Глоссарий Git.

gitnamespaces(7)
Пространства имен Git.

gitremote-helpers(7)
Вспомогательные программы для взаимодействия с удаленными репозиториями.

gitsubmodules(7)
Монтирование одного репозитория внутри другого.

gittutorial(7)
Вводное руководство по Git.

gittutorial-2(7)
Вводное руководство по Git: часть вторая.

gitworkflows(7)
Обзор рекомендуемых рабочих процессов с использованием Git.

ИНТЕРФЕЙСЫ РЕПОЗИТОРИЯ, КОМАНД И ФАЙЛОВ

Эта документация описывает интерфейсы репозитория и команд, с которыми пользователи должны взаимодействовать напрямую. См. --user-formats в git-help(1) для получения дополнительных сведений о критериях.

gitattributes(5)
Определение атрибутов для каждого пути.

gitcli(7)
Интерфейс командной строки Git и соглашения.

githooks(5)
Хуки, используемые Git.

gitignore(5)
Указывает намеренно отслеживаемые файлы, которые следует игнорировать.

gitmailmap(5)
Сопоставление имен и/или адресов электронной почты авторов и коммитеров.

gitmodules(5)
Определение свойств подмодулей.

gitrepository-layout(5)
Структура репозитория Git.

gitrevisions(7)
Указание ревизий и диапазонов для Git.

ФОРМАТЫ ФАЙЛОВ, ПРОТОКОЛЫ И ДРУГИЕ ИНТЕРФЕЙСЫ ДЛЯ РАЗРАБОТЧИКОВ

Эта документация описывает форматы файлов, протоколы обмена данными и другие интерфейсы Git для разработчиков. См. --developer-interfaces в git-help(1).

gitformat-bundle(5)
Формат файла `bundle`.

gitformat-chunk(5)
Форматы файлов на основе блоков.

gitformat-commit-graph(5)
Формат графа коммитов Git.

gitformat-index(5)
Формат индекса Git.

gitformat-pack(5)
Формат пакета Git.

gitformat-signature(5)
Форматы криптографических подписей Git.

gitprotocol-capabilities(5)
Возможности протоколов v0 и v1.

gitprotocol-common(5)
Общие элементы для различных протоколов.

gitprotocol-http(5)
Протоколы Git на основе HTTP.

gitprotocol-pack(5)
Способ передачи пакетов по сети.

gitprotocol-v2(5)
Сетевой протокол Git, версия 2.

МЕХАНИЗМ КОНФИГУРАЦИИ

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

#
# Символ '#' или ';' указывает на комментарий.
#

; переменные ядра
[core]
; Не доверять режимам файлов
filemode = false

; идентификация пользователя
[user]
name = "Junio C Hamano"
email = "_"

Различные команды читают из файла конфигурации и соответствующим образом корректируют свою работу. См. git-config(1) для получения списка и дополнительных сведений о механизме конфигурации.

ТЕРМИНОЛОГИЯ ИДЕНТИФИКАТОРОВ

<object>
Указывает имя объекта любого типа.

<blob>
Указывает имя объекта blob.

<tree>
Указывает имя объекта tree.

<commit>
Указывает имя объекта commit.

<tree-ish>
Указывает имя объекта tree, commit или tag. Команда, которая принимает аргумент `<tree-ish>`, в конечном итоге должна работать с объектом `<tree>`, но автоматически преобразует объекты `<commit>` и `<tag>`, указывающие на `<tree>`.

<commit-ish>

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

<type>

Указывает, что требуется тип объекта. В настоящее время один из следующих: blob, tree, commit или tag.

<file>

Указывает имя файла — почти всегда относительно корня структуры дерева, описанной в GIT_INDEX_FILE.

СИМВОЛИЧЕСКИЕ ИДЕНТИФИКАТОРЫ

Любая команда Git, принимающая любой <object>, также может использовать следующие символические обозначения:

HEAD

Обозначает голову текущей ветки.

<tag>

Допустимое имя тега (т. е. ссылка refs/tags/).

<head>

Допустимое имя головы (т. е. ссылка refs/heads/).

Более полный список способов указания имен объектов см. в разделе "УКАЗАНИЕ РЕВИЗИЙ" в gitrevisions(7).

СТРУКТУРА ФАЙЛОВ/ДИРЕКТОРИЙ

См. документ gitrepository-layout(5).

Подробную информацию о каждой хуке см. в githooks(5).

Более высокоуровневые системы управления версиями могут предоставлять и управлять дополнительной информацией в $GIT_DIR.

ТЕРМИНОЛОГИЯ

См. gitglossary(7).

ПЕРЕМЕННЫЕ СРЕДЫ

Различные команды Git учитывают переменные среды и изменяют свое поведение. Переменные среды, отмеченные как "Булевы", принимают свои значения так же, как булевы переменные конфигурации, т. е. "true", "yes", "on" и положительные числа принимаются как "yes", а "false", "no", "off" и "0" - как "no".

Вот переменные:

Система

HOME

Указывает путь к домашнему каталогу пользователя. В Windows, если не задано, Git устанавливает переменную среды процесса, равную: $HOMEDRIVE$HOMEPATH, если и $HOMEDRIVE, и $HOMEPATH существуют; в противном случае $USERPROFILE, если $USERPROFILE существует.

Репозиторий Git

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

GIT_INDEX_FILE

Эта переменная среды указывает альтернативный файл индекса. Если не указано, используется значение по умолчанию: $GIT_DIR/index.

GIT_INDEX_VERSION

Эта переменная среды указывает, какая версия индекса используется при записи файла индекса. Это не повлияет на существующие файлы индекса. По умолчанию используется версия 2 или 3 файла индекса. Дополнительные сведения см. в git-update-index(1).

GIT_OBJECT_DIRECTORY

Если каталог хранения объектов указан через эту переменную среды, то каталоги sha1 создаются внутри него, в противном случае используется каталог $GIT_DIR/objects по умолчанию.

GIT_ALTERNATE_OBJECT_DIRECTORIES

В связи с неизменностью объектов Git, старые объекты могут быть архивированы в общие каталоги, доступные только для чтения. Эта переменная указывает список каталогов объектов Git, разделенных символом ":" (в Windows - ";"), которые можно использовать для поиска объектов Git. Новые объекты в эти каталоги записываться не будут.

Записи, начинающиеся с " (двойной кавычки), будут интерпретироваться как пути в стиле C, при этом удаляются начальные и конечные двойные кавычки и учитываются экранированные обратной косой чертой символы. Например, значение "path-with-\"-and-:-in-it":vanilla-path содержит два пути: path-with-"-and-:-in-it и vanilla-path.

GIT_DIR

Если переменная окружения GIT_DIR установлена, то она указывает путь, который следует использовать вместо пути по умолчанию .git для базового каталога репозитория. Опция командной строки --git-dir также устанавливает это значение.

GIT_WORK_TREE

Устанавливает путь к корневому каталогу рабочей области. Этим также можно управлять с помощью опции командной строки --work-tree и переменной конфигурации core.worktree.

GIT_NAMESPACE

Устанавливает пространство имен Git; см. gitnamespaces(7) для получения подробной информации. Опция командной строки --namespace также устанавливает это значение.

GIT_CEILING_DIRECTORIES

Это должен быть список абсолютных путей, разделенных двоеточиями. Если он установлен, то это список каталогов, в которые Git не должен перемещаться вверх при поиске каталога репозитория (полезно для исключения медленно загружаемых сетевых каталогов). Он не исключит текущий рабочий каталог или GIT_DIR, установленный в командной строке или в переменной окружения. Обычно Git должен читать записи в этом списке и разрешать любые символические ссылки, которые могут присутствовать, чтобы сравнить их с текущим каталогом. Однако, если даже этот доступ медленный, вы можете добавить пустую запись в список, чтобы сообщить Git, что последующие записи не являются символическими ссылками и их не нужно разрешать; например, GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM

При запуске в каталоге, в котором нет каталога репозитория ".git", Git пытается найти такой каталог в родительских каталогах, чтобы найти верхний уровень рабочей области, но по умолчанию он не переходит границы файловых систем. Эту логическую переменную окружения можно установить в true, чтобы Git не останавливался на границах файловых систем. Как и GIT_CEILING_DIRECTORIES, это не повлияет на явно установленный каталог репозитория с помощью GIT_DIR или в командной строке.

GIT_COMMON_DIR

Если эта переменная установлена в путь, то файлы, не относящиеся к рабочей области, которые обычно находятся в $GIT_DIR, будут взяты из этого пути вместо этого. Файлы, относящиеся к рабочей области, такие как HEAD или индекс, берутся из $GIT_DIR. См. gitrepository-layout(5) и git-worktree(1) для получения подробной информации. Эта переменная имеет более низкий приоритет, чем другие переменные пути, такие как GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...

GIT_DEFAULT_HASH

Если эта переменная установлена, алгоритм хеширования по умолчанию для новых репозиториев будет установлен в это значение. Это значение игнорируется при клонировании, и всегда используется настройка удаленного репозитория. По умолчанию "sha1". См. --object-format в git-init(1).

GIT_DEFAULT_REF_FORMAT

Если эта переменная установлена, формат хранилища ссылок по умолчанию для новых репозиториев будет установлен в это значение. По умолчанию "files". См. --ref-format в git-init(1).

Коммиты Git

GIT_AUTHOR_NAME

Человекочитаемое имя, используемое в идентификаторе автора при создании объектов коммитов или тегов, или при записи журналов изменений. Переопределяет настройки user.name и author.name.

GIT_AUTHOR_EMAIL

Адрес электронной почты, используемый в идентификационных данных автора при создании объектов коммитов или тегов, или при записи журналов изменений. Переопределяет настройки user.email и author.email.

GIT_AUTHOR_DATE

Дата, используемая для идентификационных данных автора при создании объектов коммитов или тегов, или при записи журналов изменений. См. git-commit(1) для допустимых форматов.

GIT_COMMITTER_NAME

Имя, используемое в идентификационных данных коммиттера при создании объектов коммитов или тегов, или при записи журналов изменений. Переопределяет настройки user.name и committer.name.

GIT_COMMITTER_EMAIL

Адрес электронной почты, используемый в идентификационных данных коммиттера при создании объектов коммитов или тегов, или при записи журналов изменений. Переопределяет настройки user.email и committer.email.

GIT_COMMITTER_DATE

Дата, используемая для идентификационных данных коммиттера при создании объектов коммитов или тегов, или при записи журналов изменений. См. git-commit(1) для допустимых форматов.

EMAIL

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

Git Diffs

GIT_DIFF_OPTS

Единственная допустимая настройка: --unified=? или -u?, чтобы установить количество строк контекста, отображаемых при создании унифицированного патча. Это имеет приоритет над любым значением опций -U или --unified, переданным в командной строке git diff.

GIT_EXTERNAL_DIFF

Когда переменная среды GIT_EXTERNAL_DIFF установлена, вызывается программа, указанная в ней, для генерации патчей, и Git не использует свои встроенные механизмы для создания патчей. Для пути, который был добавлен, удален или изменен, GIT_EXTERNAL_DIFF вызывается с 7 параметрами:

path old-file old-hex old-mode new-file new-hex new-mode

где:

<old|new>-file
— это файлы, которые `GIT_EXTERNAL_DIFF` может использовать для чтения содержимого <old|new>,

<old|new>-hex
— это 40-значные шестнадцатеричные хэши SHA-1,

<old|new>-mode
— это восьмеричное представление режимов файлов.

Файлы-параметры могут указывать на файл, с которым работает пользователь (например, new-file в git-diff-files), /dev/null (например, old-file, когда добавляется новый файл) или временный файл (например, old-file в индексе). GIT_EXTERNAL_DIFF не должен беспокоиться об удалении временного файла — он удаляется после выхода GIT_EXTERNAL_DIFF.

Для пути, который является неслитым, GIT_EXTERNAL_DIFF вызывается с 1 параметром, <path>.

Для каждого пути, для которого вызывается GIT_EXTERNAL_DIFF, устанавливаются две переменные среды: GIT_DIFF_PATH_COUNTER и GIT_DIFF_PATH_TOTAL.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

Если эта логическая переменная среды установлена в значение true, предполагается, что команда GIT_EXTERNAL_DIFF возвращает код выхода 0, если она считает входные файлы равными, или 1, если она считает их разными, как diff(1). Если она установлена в значение false, что является значением по умолчанию, предполагается, что команда возвращает код выхода 0 независимо от равенства. Любой другой код выхода вызывает фатальную ошибку в Git.

GIT_DIFF_PATH_COUNTER
Счетчик, начинающийся с 1 и увеличивающийся на единицу для каждого пути.

GIT_DIFF_PATH_TOTAL
Общее количество путей.

other
GIT_MERGE_VERBOSITY
Число, определяющее объем вывода, отображаемого рекурсивной стратегией слияния. Переопределяет
merge.verbosity. См. git-merge(1).

GIT_PAGER
Эта переменная окружения переопределяет $PAGER. Если она установлена в пустую строку или в значение
"cat", Git не будет запускать программу постраничной навигации. См. также опцию core.pager в git-config(1).

GIT_PROGRESS_DELAY
Число, определяющее, сколько секунд нужно ждать, прежде чем отображать необязательные индикаторы прогресса.
По умолчанию — 2.

GIT_EDITOR
Эта переменная окружения переопределяет $EDITOR и $VISUAL. Она используется несколькими командами Git,
когда в интерактивном режиме необходимо запустить редактор. См. также git-var(1) и опцию
core.editor в git-config(1).

GIT_SEQUENCE_EDITOR
Эта переменная окружения переопределяет настроенный редактор Git при редактировании списка задач
интерактивного изменения истории. См. также git-rebase(1) и опцию sequence.editor в git-config(1).

GIT_SSH, GIT_SSH_COMMAND
Если какая-либо из этих переменных окружения установлена, то команды git fetch и git push будут использовать
указанную команду вместо ssh при необходимости подключения к удаленной системе. Параметры командной строки,
передаваемые в настроенную команду, определяются вариантом ssh. См. опцию ssh.variant в git-config(1) для
получения дополнительной информации.

$GIT_SSH_COMMAND имеет приоритет над $GIT_SSH и интерпретируется оболочкой, что позволяет включать дополнительные аргументы.
$GIT_SSH, с другой стороны, должен содержать только путь к программе (которая может быть оболочечным скриптом-оболочкой,
если требуются дополнительные аргументы).

Обычно проще настроить любые необходимые параметры в личном файле .ssh/config.
Обратитесь к документации ssh для получения дополнительной информации.

GIT_SSH_VARIANT
Если эта переменная окружения установлена, она переопределяет автоматическое определение Git, относится ли
GIT_SSH/GIT_SSH_COMMAND/core.sshCommand к OpenSSH, plink или tortoiseplink. Эта переменная переопределяет
настройку конфигурации ssh.variant, которая выполняет ту же функцию.

GIT_SSL_NO_VERIFY
Установка и экспорт этой переменной окружения в любое значение указывает Git не проверять сертификат SSL
при извлечении или отправке по протоколу HTTPS.

GIT_ATTR_SOURCE
Указывает дерево, из которого будут считываться атрибуты gitattributes.

GIT_ASKPASS
Если эта переменная окружения установлена, то команды Git, которым необходимо получать пароли или парольные фразы
(например, для аутентификации HTTP или IMAP), будут вызывать эту программу с подходящим запросом в качестве аргумента
командной строки и считывать пароль из ее стандартного вывода. См. также опцию core.askPass в git-config(1).

GIT_TERMINAL_PROMPT
Если эта логическая переменная окружения установлена в false, Git не будет запрашивать данные в терминале
(например, при запросе аутентификации HTTP).

GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
Используют конфигурацию из указанных файлов вместо глобальных или системных файлов конфигурации. Если
GIT_CONFIG_SYSTEM установлена, системный файл конфигурации, определенный во время сборки (обычно /etc/gitconfig),
не будет читаться. Аналогично, если GIT_CONFIG_GLOBAL установлена, ни $HOME/.gitconfig, ни
$XDG_CONFIG_HOME/git/config не будут читаться. Можно установить значение /dev/null, чтобы пропустить чтение
файлов конфигурации соответствующего уровня.

GIT_CONFIG_NOSYSTEM

Определяет, следует ли пропускать чтение настроек из общесистемного файла $(prefix)/etc/gitconfig. Эта булева переменная среды может использоваться вместе с $HOME и $XDG_CONFIG_HOME для создания предсказуемой среды для требовательного скрипта, или ее можно установить в true, чтобы временно избежать использования некорректного файла /etc/gitconfig до тех пор, пока кто-нибудь с достаточными правами не исправит его.

GIT_FLUSH

Если эта булева переменная среды установлена в true, то такие команды, как git blame (в инкрементном режиме), git rev-list, git log, git check-attr и git check-ignore, будут принудительно очищать выходной поток после вывода каждой записи. Если эта переменная установлена в false, вывод этих команд будет выполняться с использованием полностью буферизованного ввода-вывода. Если эта переменная среды не установлена, Git будет выбирать буферизованный или запись-ориентированный сброс на основе того, перенаправлен ли stdout в файл или нет.

GIT_TRACE

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

Если эта переменная установлена в "1", "2" или "true" (сравнение не учитывает регистр), сообщения трассировки будут выводиться в stderr.

Если переменная установлена в целочисленное значение, большее 2 и меньшее 10 (строго), Git интерпретирует это значение как дескриптор открытого файла и попытается записывать сообщения трассировки в этот дескриптор файла.

В качестве альтернативы, если переменная установлена в абсолютный путь (начинающийся с символа /), Git интерпретирует это как путь к файлу и попытается добавить сообщения трассировки в него.

Отмена установки переменной или установка ее в пустую строку, "0" или "false" (без учета регистра) отключает сообщения трассировки.

GIT_TRACE_FSMONITOR

Включает сообщения трассировки для расширения файловой системы. См. GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_PACK_ACCESS

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

GIT_TRACE_PACKET

Включает сообщения трассировки для всех пакетов, поступающих или отправляемых данной программой. Это может помочь в отладке проблем с согласованием объектов или других проблем протокола. Трассировка отключается при поступлении пакета, начинающегося с "PACK" (но см. GIT_TRACE_PACKFILE ниже). См. GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_PACKFILE

Включает трассировку файлов пакетов, отправляемых или получаемых данной программой. В отличие от других выходных данных трассировки, эта трассировка является буквальной: без заголовков и без цитирования двоичных данных. Вам почти наверняка захочется перенаправлять ее в файл (например, GIT_TRACE_PACKFILE=/tmp/my.pack), а не отображать в терминале или смешивать с другими выходными данными трассировки.

Обратите внимание, что в настоящее время это реализовано только для клиентской части операций клонирования и извлечения.

GIT_TRACE_PERFORMANCE
Включает сообщения трассировки, связанные с производительностью, например, общее время выполнения каждой команды Git.
Смотрите GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_REFS
Включает сообщения трассировки для операций с базой данных ссылок. Смотрите GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_SETUP
Включает сообщения трассировки, выводящие информацию о каталоге .git, рабочей области и текущем рабочем каталоге после завершения Git этапа настройки. Смотрите GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_SHALLOW
Включает сообщения трассировки, которые могут помочь в отладке операций извлечения/клонирования неглубоких репозиториев.
Смотрите GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_CURL
Включает полную трассировку curl для всех входящих и исходящих данных, включая описательную информацию, протокола git transport. Это аналогично использованию curl --trace-ascii в командной строке. Смотрите GIT_TRACE для доступных параметров вывода трассировки.

GIT_TRACE_CURL_NO_DATA
Когда включена трассировка curl (см. GIT_TRACE_CURL выше), не выводить данные (то есть, выводить только информационные строки и заголовки).

GIT_TRACE2
Включает более подробные сообщения трассировки из библиотеки "trace2". Вывод GIT_TRACE2 представляет собой простой текстовый формат для удобства чтения.

Если эта переменная установлена в "1", "2" или "true" (сравнение не учитывает регистр), сообщения трассировки будут выводиться в stderr.

Если переменная установлена в целочисленное значение больше 2 и меньше 10 (строго), Git интерпретирует это значение как дескриптор открытого файла и попытается записать сообщения трассировки в этот дескриптор файла.

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

Кроме того, если переменная установлена в af_unix:[<socket-type>:]<absolute-pathname>, Git попытается открыть путь как сокет Unix Domain. Тип сокета может быть либо stream, либо dgram.

Отключение переменной или установка ее в пустую строку, "0" или "false" (без учета регистра) отключает сообщения трассировки.

Смотрите документацию Trace2[2] для получения полной информации.

GIT_TRACE2_EVENT
Эта настройка записывает данные в формате JSON, который подходит для машинной интерпретации. Смотрите GIT_TRACE2 для доступных параметров вывода трассировки и документацию Trace2[2] для получения полной информации.

GIT_TRACE2_PERF
В дополнение к текстовым сообщениям, доступным в GIT_TRACE2, эта настройка записывает данные в формате с разделителями столбцов для понимания вложенных областей. Смотрите GIT_TRACE2 для доступных параметров вывода трассировки и документацию Trace2[2] для получения полной информации.

GIT_TRACE_REDACT

По умолчанию, при включенной трассировке, Git скрывает значения файлов cookie, заголовка "Authorization:", заголовка "Proxy-Authorization:" и URI файлов пакетов. Установите эту булеву переменную среды в значение "false", чтобы предотвратить это скрытие.

GIT_NO_REPLACE_OBJECTS

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

GIT_LITERAL_PATHSPECS

Установка этой булевой переменной среды в значение "true" приведет к тому, что Git будет интерпретировать все pathspec буквально, а не как шаблоны glob. Например, при запуске GIT_LITERAL_PATHSPECS=1 git log -- '\*.c' будет осуществлен поиск коммитов, затрагивающих путь *.c, а не любые пути, соответствующие шаблону glob *.c. Это может быть полезно, если вы передаете Git литеральные пути (например, пути, ранее полученные от git ls-tree, вывод --raw diff и т. д.).

GIT_GLOB_PATHSPECS

Установка этой булевой переменной среды в значение "true" приведет к тому, что Git будет интерпретировать все pathspec как шаблоны glob (также известные как "glob magic").

GIT_NOGLOB_PATHSPECS

Установка этой булевой переменной среды в значение "true" приведет к тому, что Git будет интерпретировать все pathspec как литералы (также известные как "literal magic").

GIT_ICASE_PATHSPECS

Установка этой булевой переменной среды в значение "true" приведет к тому, что Git будет интерпретировать все pathspec без учета регистра.

GIT_NO_LAZY_FETCH

Установка этой булевой переменной среды в значение "true" указывает Git не выполнять ленивую загрузку отсутствующих объектов из удаленного репозитория по требованию.

GIT_REFLOG_ACTION

При обновлении ссылки создаются записи в журнале изменений (reflog), чтобы отслеживать причину обновления ссылки (обычно это имя команды верхнего уровня, которая обновила ссылку), в дополнение к старым и новым значениям ссылки. Скриптованная команда Porcelain может использовать вспомогательную функцию set_reflog_action в git-sh-setup, чтобы установить ее имя в этой переменной, когда она вызывается как команда верхнего уровня конечным пользователем, чтобы ее можно было записать в тело reflog.

GIT_REF_PARANOIA

Если эта булева переменная среды установлена в "false", игнорируйте поврежденные или неправильно названные ссылки при итерации по спискам ссылок. Обычно Git пытается включить все такие ссылки, что может привести к сбою некоторых операций. Обычно предпочтительнее, чтобы потенциально опасные операции (например, git-prune(1)) завершались, а не игнорировали поврежденные ссылки (и, следовательно, считали, что история, на которую они указывают, не стоит сохранять). Значение по умолчанию — 1 (т. е. будьте параноидальны в отношении обнаружения и прерывания всех операций). Обычно вам не нужно устанавливать это значение в 0, но это может быть полезно при попытке восстановить данные из поврежденного репозитория.

GIT_COMMIT_GRAPH_PARANOIA

При загрузке объекта коммита из графа коммитов Git выполняет проверку существования объекта в базе объектов. Это делается для предотвращения проблем с устаревшими графами коммитов, содержащими ссылки на уже удаленные коммиты, но это имеет последствия для производительности.

Значение по умолчанию — "false", что отключает вышеупомянутое поведение. Установка этого значения в "true" включает проверку существования, чтобы устаревшие коммиты никогда не возвращались из графа коммитов, но это снижает производительность.

GIT_ALLOW_PROTOCOL

Если установлено значение в виде списка протоколов, разделенных двоеточием, то поведение будет таким, как если бы protocol.allow было установлено в never, и для каждого из перечисленных протоколов protocol.<name>.allow было установлено в always (переопределяя любую существующую конфигурацию). См. описание protocol.allow в git-config(1) для получения дополнительной информации.

GIT_PROTOCOL_FROM_USER

Установите эту булеву переменную среды в false, чтобы запретить использование протоколов, используемых командами fetch/push/clone, которые настроены в пользовательском состоянии. Это полезно для ограничения рекурсивной инициализации подмодулей из ненадежного репозитория или для программ, которые передают потенциально ненадежные URL-адреса командам git. См. git-config(1) для получения дополнительной информации.

GIT_PROTOCOL

Только для внутреннего использования. Используется при установлении связи по сетевому протоколу. Содержит список ключей, разделенных двоеточием, с необязательными значениями <key>[=<value>]. Наличие неизвестных ключей и значений должно игнорироваться.

Обратите внимание, что серверы могут потребовать настройки для разрешения передачи этой переменной по некоторым транспортным протоколам. Она будет автоматически распространяться при доступе к локальным репозиториям (т. е. file:// или путь к файловой системе), а также по протоколу git://. Для git-over-http это должно работать автоматически в большинстве конфигураций, но см. обсуждение в git-httpbackend(1). Для git-over-ssh сервер ssh может потребовать настройки для разрешения клиентам передавать эту переменную (например, с помощью AcceptEnv GIT_PROTOCOL в OpenSSH).

Эта конфигурация является необязательной. Если переменная не передается, то клиенты вернутся к исходному протоколу "v0" (но могут упустить некоторые улучшения производительности или функции). В настоящее время эта переменная влияет только на клонирование и извлечение; она еще не используется для отправки (но может использоваться в будущем).

GIT_OPTIONAL_LOCKS

Если эта булева переменная среды установлена в false, Git выполнит любое запрошенное действие без выполнения каких-либо дополнительных операций, требующих получения блокировки. Например, это предотвратит обновление индекса командой git status в качестве побочного эффекта. Это полезно для процессов, работающих в фоновом режиме, которые не хотят вызывать конфликты блокировок с другими операциями в репозитории. По умолчанию равно 1.

GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR

Только для Windows: позволяет перенаправлять дескрипторы стандартного ввода/вывода/ошибок в пути, указанные переменными среды. Это особенно полезно в многопоточных приложениях, где стандартный способ передачи дескрипторов через CreateProcess() невозможен, поскольку это потребовало бы, чтобы дескрипторы были помечены как наследуемые (и, следовательно, каждый созданный процесс наследует их, что может блокировать обычные операции Git). Основная предполагаемая цель — использовать именованные каналы для связи (например, \\.\pipe\my-git-stdin-123).

Поддерживаются два специальных значения: off просто закроет соответствующий стандартный дескриптор, а если GIT_REDIRECT_STDERR имеет значение 2>&1, стандартный вывод ошибок будет перенаправлен в тот же дескриптор, что и стандартный вывод.

GIT_PRINT_SHA1_ELLIPSIS (устарело)

Если установлено значение "yes", после (сокращенного) SHA-1 значения будет выводиться многоточие. Это влияет на отображение отсоединенных HEAD-ов (git-checkout(1)) и на вывод изменений в формате "raw" (git-diff(1)). Вывод многоточия в указанных случаях больше не считается подходящим, и поддержка этой функции, скорее всего, будет удалена в ближайшем будущем (вместе с переменной).

GIT_ADVICE

Если установлено значение 0, то отключаются все сообщения-подсказки. Эти сообщения предназначены для предоставления пользователям советов, которые могут помочь им выйти из проблемных ситуаций или воспользоваться новыми функциями. Пользователи могут отключить отдельные сообщения, используя ключи конфигурации advice.*. Эти сообщения могут мешать работе инструментов, выполняющих процессы Git, поэтому эта переменная позволяет отключить сообщения. (Глобальная опция --no-advice также доступна, но старые версии Git могут не распознавать ее. Переменная среды будет игнорироваться версиями Git, которые ее не поддерживают.)

ОБСУЖДЕНИЕ

Более подробная информация приведена в главе "Основные концепции Git" в руководстве пользователя [3] и в gitcore-tutorial(7).

Обычно проект Git состоит из рабочей директории с поддиректорией ".git" в корневом каталоге. Директория ".git" содержит, в частности, сжатую базу данных объектов, представляющую полную историю проекта, файл "индекса", который связывает эту историю с текущим содержимым рабочей области, и именованные указатели в этой истории, такие как теги и головные ветви.

Объектная база данных содержит объекты трех основных типов: blobs, которые хранят данные файлов; trees, которые указывают на blobs и другие trees, создавая иерархии директорий; и commits, которые каждый ссылается на одно tree и некоторое количество родительских commits.

Commit, эквивалентный тому, что другие системы называют "набором изменений" или "версией", представляет собой шаг в истории проекта, и каждый родитель представляет непосредственно предшествующий шаг. Commits с более чем одним родителем представляют собой слияние независимых ветвей разработки.

Все объекты имеют имена, которые представляют собой SHA-1 хэш их содержимого, обычно записываемый в виде строки из 40 шестнадцатеричных цифр. Такие имена глобально уникальны. Всю историю, ведущую к commit, можно подтвердить, подписав только этот commit. Для этой цели предоставляется четвертый тип объекта — tag.

При создании объекты хранятся в отдельных файлах, но для повышения эффективности их можно позже сжать в "пакетные файлы".

Именованные указатели, называемые refs, отмечают интересные точки в истории. Ref может содержать SHA-1 имя объекта или имя другого ref (последнее называется "символьным ref"). Refs, имена которых начинаются с refs/heads/, содержат SHA-1 имя последнего commit (или "головы") разрабатываемой ветви. SHA-1 имена интересующих тегов хранятся в refs/tags/. Символьный ref с именем HEAD содержит имя текущей рабочей ветви.

Файл индекса инициализируется списком всех путей, и для каждого пути создается объект blob и набор атрибутов. Объект blob представляет содержимое файла на момент HEAD текущей ветки. Атрибуты (время последнего изменения, размер и т. д.) берутся из соответствующего файла в рабочей области. Последующие изменения в рабочей области можно обнаружить, сравнив эти атрибуты. Индекс можно обновить новым содержимым, и из содержимого, хранящегося в индексе, можно создать новые коммиты.

Индекс также может хранить несколько записей (называемых «стадиями») для заданного имени пути. Эти стадии используются для хранения различных неслитых версий файла, когда выполняется слияние.

БЕЗОПАСНОСТЬ

Некоторые параметры конфигурации и файлы хуков могут приводить к тому, что Git будет выполнять произвольные команды оболочки. Поскольку конфигурация и хуки не копируются при использовании git clone, обычно безопасно клонировать удаленные репозитории с ненадежным содержимым, просматривать их с помощью git log и т. д.

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

По умолчанию Git откажется работать, если репозиторий принадлежит не тому пользователю, который выполняет команду. См. запись для safe.directory в git-config(1). Хотя это может помочь защитить вас в многопользовательской среде, имейте в виду, что вы также можете получить ненадежные репозитории, которые принадлежат вам (например, если вы извлекаете zip-файл или tar-архив из ненадежного источника). В таких случаях вам сначала потребуется «очистить» ненадежный репозиторий.

Если у вас есть ненадежный каталог .git, сначала клонируйте его с помощью git clone --no-local, чтобы получить чистую копию. Git ограничивает набор параметров и хуков, которые будут выполняться upload-pack, который обрабатывает серверную часть клонирования или выборки, но имейте в виду, что область атак на upload-pack велика, поэтому это связано с определенным риском. Самое безопасное — обслуживать репозиторий как непривилегированного пользователя (либо через git-daemon(1), ssh или с помощью других инструментов для изменения идентификаторов пользователей). См. обсуждение в разделе «БЕЗОПАСНОСТЬ» в git-upload-pack(1).

ДАЛЬНЕЙШАЯ ДОКУМЕНТАЦИЯ

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

Глава «Концепции Git» в руководстве пользователя[3] и gitcore-tutorial(7) содержат введение в базовую архитектуру Git.

См. gitworkflows(7) для обзора рекомендуемых рабочих процессов.

См. также документы howto[4] для получения полезных примеров.

Внутренние компоненты документированы в документации API Git[5].

Пользователи, переходящие с CVS, также могут ознакомиться с gitcvs-migration(7).

АВТОРЫ

Git был начат Линусом Торвальдсом, в настоящее время его поддерживает Джунио C. Хамано. Множество вкладов поступает из списка рассылки Git <_[6]>. https://openhub.net/p/git/contributors/summary предоставляет более полный список участников.

Если у вас есть клон репозитория git.git, вывод команд git-shortlog(1) и git-blame(1) может показать вам авторов конкретных частей проекта.

СООБЩЕНИЕ ОБ ОШИБКАХ

Сообщайте об ошибках в почтовой рассылке Git <_[6]>, где в основном ведется разработка и поддержка. Вам не обязательно быть подписчиком списка рассылки, чтобы отправить туда сообщение. Посмотрите архив списка рассылки на https://lore.kernel.org/git для просмотра предыдущих отчетов об ошибках и других обсуждений.

Вопросы, связанные с безопасностью, следует сообщать конфиденциально в почтовую рассылку Git Security <_[7]>.

СМОТРИТЕ ТАКЖЕ

gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcoretutorial(7), gitcli(7), Руководство пользователя Git[1], gitworkflows(7)

GIT

Часть пакета git(1)

ПРИМЕЧАНИЯ

    Руководство пользователя Git
file:///usr/share/doc/git/html/user-manual.html

    Документация Trace2
file:///usr/share/doc/git/html/technical/api-trace2.html

    Глава «Концепции Git» из руководства пользователя
file:///usr/share/doc/git/html/user-manual.html#git-concepts

howto
file:///usr/share/doc/git/html/howto-index.html

    Документация по API Git
file:///usr/share/doc/git/html/technical/api-index.html

_
mailto:_

_
mailto:_