Русский ▾ Topics ▾ Latest version ▾ git last updated in 2.54.0

НАЗВАНИЕ

git — глупый трекер содержимого

ОБЗОР

git [--version] [--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.

После того как вы освоили основные концепции, вы можете вернуться на эту страницу, чтобы узнать, какие команды предлагает Git. Вы можете узнать больше об отдельных командах Git с помощью «git help команда». Страница руководства 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=<имя>=<переменная-среды>

Как -c <имя>=<значение>, присваивает значение переменной конфигурации <имя>, где <переменная-среды> — это имя переменной среды, из которой нужно получить значение. В отличие от -c, нет ярлыка для прямой установки значения в пустую строку, вместо этого сама переменная среды должна быть установлена в пустую строку. Ошибкой является отсутствие <переменной-среды> в среде. <переменная-среды> не может содержать знак равенства, чтобы избежать неоднозначности с <имя>, содержащим его.

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

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

--exec-path[=<путь>]

Путь к месту установки основных программ Git. Это также можно контролировать, установив переменную среды GIT_EXEC_PATH. Если путь не указан, git выведет текущую настройку и завершится.

--html-path

Вывести путь (без конечного слеша), где установлена HTML-документация Git, и завершиться.

--man-path

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

--info-path

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

-p
--paginate

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

-P
--no-pager

Не перенаправлять вывод Git в пейджер.

--git-dir=<путь>

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

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

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

--work-tree=<путь>

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

--namespace=<путь>

Установить пространство имён 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 <объект>, чтобы увидеть, доступен ли объект локально. Это эквивалентно установке переменной среды 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=<группа>[,<группа>…​]

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

--attr-source=<указатель-дерева>

Читать gitattributes из <указателя-дерева> вместо рабочего каталога. См. gitattributes[5]. Это эквивалентно установке переменной среды GIT_ATTR_SOURCE.

КОМАНДЫ GIT

Мы разделяем Git на высокоуровневые («porcelain») команды и низкоуровневые («plumbing») команды.

Высокоуровневые команды (фарфор)

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

Основные пользовательские команды

Warning

Missing ru/{build_dir}/cmds-mainporcelain.adoc

See original version for this content.

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

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

Warning

Missing ru/{build_dir}/cmds-ancillarymanipulators.adoc

See original version for this content.

Опросчики:

Warning

Missing ru/{build_dir}/cmds-ancillaryinterrogators.adoc

See original version for this content.

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

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

Warning

Missing ru/{build_dir}/cmds-foreignscminterface.adoc

See original version for this content.

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

Существует три команды с похожими именами: 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].

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

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

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

Warning

Missing ru/{build_dir}/cmds-plumbingmanipulators.adoc

See original version for this content.

Команды запроса

Warning

Missing ru/{build_dir}/cmds-plumbinginterrogators.adoc

See original version for this content.

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

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

Warning

Missing ru/{build_dir}/cmds-synchingrepositories.adoc

See original version for this content.

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

Warning

Missing ru/{build_dir}/cmds-synchelpers.adoc

See original version for this content.

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

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

Warning

Missing ru/{build_dir}/cmds-purehelpers.adoc

See original version for this content.

Руководства

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

Warning

Missing ru/{build_dir}/cmds-guide.adoc

See original version for this content.

Интерфейсы репозитория, команд и файлов

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

Warning

Missing ru/{build_dir}/cmds-userinterfaces.adoc

See original version for this content.

Форматы файлов, протоколы и другие интерфейсы разработчика

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

Warning

Missing ru/{build_dir}/cmds-developerinterfaces.adoc

See original version for this content.

Механизм конфигурации

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

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

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

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

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

Терминология идентификаторов

<объект>

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

<blob-объект>

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

<tree>

Указывает имя объекта-дерева.

<коммит>

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

<указатель-дерева>

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

<указатель-на-коммит>

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

<type>

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

<file>

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

Символьные идентификаторы

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

HEAD

указывает голову текущей ветки.

<метка>

допустимая метка имя (т.е. ссылка refs/tags/<метка>).

<голова>

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

Более полный список способов написания имён объектов см. в разделе "ЗАДАНИЕ РЕВИЗИЙ" в gitrevisions[7].

Структура файлов/каталогов

Пожалуйста, обратитесь к документу gitrepository-layout[5].

Прочитайте githooks[5] для получения более подробной информации о каждом перехватчике.

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

Терминология

Пожалуйста, обратитесь к gitglossary[7].

Переменные окружения

Различные команды Git обращают внимание на переменные среды и изменяют своё поведение. Переменные среды, помеченные как "Boolean", принимают свои значения так же, как и переменные конфигурации с булевыми значениями, т.е. "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 старые объекты могут быть архивированы в общие каталоги только для чтения. Эта переменная задаёт разделённый ":" (в Windows разделённый ";") список каталогов объектов Git, которые можно использовать для поиска объектов Git. Новые объекты не будут записываться в эти каталоги.

Записи, начинающиеся с " (двойной кавычки), будут интерпретироваться как пути в кавычках в стиле C, с удалением начальных и конечных двойных кавычек и с учётом escape-последовательностей с обратной косой чертой. Например, значение "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=/возможно/символьная_ссылка::/очень/медленный/не/символьная_ссылка.

GIT_DISCOVERY_ACROSS_FILESYSTEM

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

GIT_COMMON_DIR

Если эта переменная установлена в путь, файлы, не относящиеся к рабочему каталогу, которые обычно находятся в $GIT_DIR, будут взяты из этого пути вместо этого. Файлы, специфичные для рабочего каталога, такие как HEAD или index, берутся из $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

GIT_DIFF_OPTS

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

GIT_EXTERNAL_DIFF

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

путь старый-файл старый-hex старый-режим новый-файл новый-hex новый-режим

где:

<старый|новый>-file

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

<старый|новый>-hex

это 40-шестнадцатеричные хеши SHA-1,

<старый|новый>-mode

это восьмеричное представление режимов файлов.

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

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

Для каждого пути, для которого вызывается 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

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

другое

GIT_MERGE_VERBOSITY

Число, управляющее объёмом вывода, показываемого рекурсивной стратегией слияния. Переопределяет merge.verbosity. См. git-merge[1]

GIT_PAGER

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

GIT_PROGRESS_DELAY

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

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), вызовут эту программу с соответствующим приглашением в качестве аргумента командной строки и прочитают пароль из её STDOUT. См. также параметр 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

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

GIT_TRACE_PACKET

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

GIT_TRACE_PACKFILE

Включает трассировку pack-файлов, отправленных или полученных данной программой. В отличие от других выводов трассировки, эта трассировка является буквальной: без заголовков и без заключения двоичных данных в кавычки. Вы почти наверняка захотите направить её в файл (например, 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. Это похоже на выполнение 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:[<тип-сокета>:]<абсолютное-имя-пути>, Git попытается открыть путь как сокет домена Unix. Тип сокета может быть либо stream, либо dgram.

Снятие переменной или установка её в пустое значение, «0» или «false» (нечувствительно к регистру) отключает трассировочные сообщения.

Полные сведения см. в документации Trace2.

GIT_TRACE2_EVENT

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

GIT_TRACE2_PERF

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

GIT_TRACE_REDACT

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

GIT_NO_REPLACE_OBJECTS

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

GIT_LITERAL_PATHSPECS

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

GIT_GLOB_PATHSPECS

Установка этой булевой переменной среды в true заставит Git обрабатывать все спецификаторы пути как шаблоны glob (также известные как магия "glob").

GIT_NOGLOB_PATHSPECS

Установка этой булевой переменной среды в true заставит Git обрабатывать все спецификаторы пути как буквальные (также известные как магия "literal").

GIT_ICASE_PATHSPECS

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

GIT_NO_LAZY_FETCH

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

GIT_REFLOG_ACTION

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

GIT_REF_PARANOIA

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

GIT_COMMIT_GRAPH_PARANOIA

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

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

GIT_ALLOW_PROTOCOL

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

GIT_PROTOCOL_FROM_USER

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

GIT_PROTOCOL

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

Обратите внимание, что серверы, возможно, должны быть настроены, чтобы разрешить передачу этой переменной через некоторые транспорты. Она будет автоматически передаваться при доступе к локальным репозиториям (т.е. file:// или пути файловой системы), а также через протокол git://. Для git-over-http в большинстве конфигураций это должно работать автоматически, но см. обсуждение в git-http-backend[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]) и на необработанный вывод сравнения (git-diff[1]). Вывод многоточия в упомянутых случаях больше не считается адекватным, и поддержка этого, вероятно, будет удалена в обозримом будущем (вместе с переменной).

GIT_ADVICE

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

Обсуждение

Более подробная информация о следующем доступна в главе о концепциях Git руководства пользователя и gitcore-tutorial[7].

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

База данных объектов содержит объекты трёх основных типов: blob-объекты, которые содержат данные файлов; деревья, которые указывают на blob-объекты и другие деревья для построения иерархий каталогов; и коммиты, каждый из которых ссылается на одно дерево и некоторое количество родительских коммитов.

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

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

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

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

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

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

ЗАЩИТА

Некоторые параметры конфигурации и файлы перехватчиков могут заставить 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, либо с помощью других инструментов для изменения идентификаторов пользователей). См. обсуждение в разделе SECURITY документации git-upload-pack[1].

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

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

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

Обзор рекомендуемых рабочих процессов см. в gitworkflows[7].

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

Внутреннее устройство документировано в документации Git API.

Пользователям, мигрирующим с CVS, также может быть полезно прочитать gitcvs-migration[7].

Авторы

Git был начат Линусом Торвальдсом и в настоящее время поддерживается Джунио К Хамано. Многочисленные вклады поступили из списка рассылки Git <git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary предоставляет вам более полный список участников.

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

Сообщение об ошибках

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

Проблемы, связанные с безопасностью, должны раскрываться в частном порядке списку рассылки Git Security <git-security@googlegroups.com>.

GIT

Является частью пакета git[1]