Данные, следующие за ключевым словом gitdir и двоеточием, используются в качестве glob-шаблона. Если местоположение каталога .git соответствует шаблону, условие включения выполнено.

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

Данные, следующие за ключевым словом onbranch и двоеточием, интерпретируются как шаблон со стандартными wildcard-символами glob и двумя дополнительными, **/ и /**, которые могут соответствовать нескольким компонентам пути. Если мы находимся в рабочей копии, где имя ветки, которая в данный момент переключена, соответствует шаблону, условие включения выполнено.

Данные, следующие за этим ключевым словом и двоеточием, интерпретируются как шаблон со стандартными wildcard-символами glob и двумя дополнительными, **/ и /**, которые могут соответствовать нескольким компонентам. При первом обнаружении этого ключевого слова остальная часть файлов конфигурации будет просканирована на наличие внешних URL-адресов (без применения каких-либо значений). Если существует хотя бы один внешний URL-адрес, соответствующий этому шаблону, условие включения выполнено.

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

Значение для многих переменных, указывающих различные размеры, может иметь суффикс k, M,…​ означающий "умножить число на 1024", "на 1024x1024" и т.д.

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

Переменной, принимающей путь в качестве значения, можно передать строку, начинающуюся с "~/" или "~user/", и для такой строки выполняется обычное тильда-раскрытие: ~/ раскрывается в значение $HOME, а ~user/ — в домашний каталог указанного пользователя.

Даёт указание git.add продолжить добавление файлов в ситуации, когда не удалось добавить некоторые файлы из-за ошибок индексирования. Эквивалентно параметру --ignore-errors git-add[1]. add.ignore-errors считается устаревшим (deprecated), так как он не следует устоявшимся конвенциям наименования переменных конфигурации.

Указывает git branch, git switch и git checkout настраивать новые ветки так, чтобы git-pull[1] соответствующим образом выполнял слияние из начальной ветки. Обратите внимание, что даже если этот параметр не установлен, это поведение можно выбрать для каждой ветки с помощью опций --track и --no-track. Этот параметр по умолчанию имеет значение true. Допустимые настройки:

Когда создаётся новая ветка с помощью git branch, git switch или git checkout, которая отслеживает другую ветку, эта переменная указывает Git настроить извлечение (pull) на перемещение (rebase) вместо слияния (merge) (см. branch.<имя>.rebase). Допустимые настройки:

Эта переменная управляет порядком сортировки веток при отображении git-branch[1]. Если не указана опция --sort=<значение>, значение этой переменной будет использоваться по умолчанию. Допустимые значения см. в названиях полей git-for-each-ref[1].

Находясь в ветке <имя>, указывает git fetch и git push, из какого внешнего репозитория получать или в какой отправлять. Внешний репозиторий для отправки может быть переопределён с помощью remote.pushDefault (для всех веток). Внешний репозиторий для отправки для текущей ветки может быть дополнительно переопределён с помощью branch.<имя>.pushRemote. Если внешний репозиторий не настроен или если вы не находитесь ни в какой ветке и в репозитории определено более одного внешнего репозитория, по умолчанию для получения используется origin, а для отправки — remote.pushDefault. Кроме того, . (точка) — это текущий локальный репозиторий (dot-репозиторий); см. последнее примечание к branch.<имя>.merge ниже.

Находясь в ветке <имя>, переопределяет branch.<имя>.remote для отправки. Он также переопределяет remote.pushDefault для отправки из ветки <имя>. Когда вы извлекаете (pull) из одного места (например, вашего вышестоящего (upstream) репозитория) и отправляете в другое (например, в свой собственный публичный репозиторий), вы захотите установить remote.pushDefault, чтобы указать внешний репозиторий для отправки для всех веток, и использовать этот параметр, чтобы переопределить его для конкретной ветки.

Определяет вместе с branch.<имя>.remote вышестоящую (upstream) ветку для данной ветки. Он сообщает git fetch/git pull/git rebase, какую ветку сливать (merge), и также может влиять на git push (см. push.default). Находясь в ветке <имя>, он сообщает git fetch спецификатор ссылки по умолчанию, который должен быть помечен для слияния в FETCH_HEAD. Значение обрабатывается как внешняя часть спецификатора ссылки и должно соответствовать ссылке, которая извлекается из внешнего репозитория, указанного в branch.<имя>.remote. Информация о слиянии используется git pull (который сначала вызывает git fetch) для поиска ветки по умолчанию для слияния. Без этой опции git pull по умолчанию сливает первый полученный спецификатор ссылки. Укажите несколько значений, чтобы получить слияние octopus. Если вы хотите настроить git pull так, чтобы он сливался в <имя> из другой ветки в локальном репозитории, вы можете указать branch.<имя>.merge на нужную ветку и использовать настройку относительного пути . (точка) для branch.<имя>.remote.

Устанавливает параметры по умолчанию для слияния в ветку <имя>. Синтаксис и поддерживаемые параметры такие же, как в git-merge[1], но значения параметров, содержащие пробельные символы, в настоящее время не поддерживаются.

Если true, переместить (rebase) ветку <имя> поверх полученной ветки вместо слияния ветки по умолчанию из внешнего репозитория по умолчанию при выполнении git pull. См. pull.rebase для выполнения этого неспецифичным для ветки способом.

Описание ветки, можно редактировать с помощью git branch --edit-description. Описание ветки автоматически добавляется в сопроводительное письмо format-patch или сводку request-pull.

Когда вы запускаете git checkout <что-то> или git switch <что-то> и у вас есть только один внешний репозиторий, он может неявно переключиться на отслеживание, например, origin/<что-то>. Это перестаёт работать, как только у вас появляется более одного внешнего репозитория со ссылкой <что-то>. Этот параметр позволяет задать имя предпочтительного внешнего репозитория, который всегда должен побеждать при разрешении неоднозначности. Типичный вариант использования — установить это значение в origin.

Предоставляет значение по умолчанию для опции --guess или --no-guess в git checkout и git switch. См. git-switch[1] и git-checkout[1].

Количество параллельных рабочих процессов, используемых при обновлении рабочего каталога. По умолчанию — один, т.е. последовательное выполнение. Если установлено значение меньше единицы, Git будет использовать столько рабочих процессов, сколько доступно логических ядер. Этот параметр и checkout.thresholdForParallelism влияют на все команды, выполняющие переключение (checkout). Например, checkout, clone, reset, sparse-checkout и т.д.

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

Имя, которое будет использоваться для удалённого репозитория при его клонировании. По умолчанию: origin. Его можно переопределить, передав git-clone[1] параметр командной строки --origin.

Отказаться от клонирования репозитория, если он является частичным (shallow); это поведение можно переопределить, передав параметр командной строки --reject-shallow. См. git-clone[1].

Если задан фильтр частичного клонирования (см. --filter в git-rev-list[1]) и используется --recurse-submodules, то применять фильтр также и к подмодулям.

Этот параметр переопределяет значение по умолчанию опции --cleanup в git commit. See git-commit[1] for details. Изменение значения по умолчанию может быть полезно, если вы всегда хотите оставлять строки, начинающиеся с символа комментария (core.commentChar, по умолчанию #), в вашем сообщении журнала, и в этом случае вы сделаете git config commit.cleanup whitespace (обратите внимание, что вам придётся самостоятельно удалять строки помощи, начинающиеся с символа комментария, в шаблоне сообщения коммита, если вы это сделаете).

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

Логическое значение, для включения/отключения вывода информации о состоянии в шаблоне сообщения коммита при использовании редактора для подготовки сообщения. По умолчанию: true.

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

Логическое или целочисленное значение, задающее уровень подробностей, добавляемых git commit в шаблон сообщений коммитов. See git-commit[1] for details.

При использовании git diff для сравнения с файлами в рабочем каталоге не учитывать изменения, касающиеся только stat-информации файлов. Вместо этого выполняется команда git update-index --refresh для обновления кэшированной stat-информации о путях, содержимое которых в рабочем каталоге совпадает с содержимым в индексе. Эта переменная по умолчанию установлена в значение true. Обратите внимание, что это влияет только на высокоуровневую команду git diff, но не на команды сравнения более низкого уровня, такие как git diff-files.

Список аргументов --dirstat, разделённых запятыми, которые определяют поведение по умолчанию параметра --dirstat команды git-diff[1] и других ей аналогичных. Аргументы по умолчанию можно переопределить в командной строке (с помощью --dirstat=<аргумент>,...). Аргументы по умолчанию (когда переменная diff.dirstat не изменена): changes,noncumulative,3. Допустимые аргументы:

Ограничивает длину имени файла (или его части) в выводе --stat. Если установлено, применяется ко всем командам, генерирующим вывод --stat, кроме format-patch.

Ограничивает длину «графической» части в выводе --stat. Если установлено, применяется ко всем командам, генерирующим вывод --stat, кроме format-patch.

Генерировать списки изменений с <n> строками контекста вместо стандартных 3. Это значение переопределяется параметром -U.

Показывать до указанного количества строк в качестве контекста между отдельными блоками списков изменений, тем самым объединяя те блоки, которые находятся рядом друг с другом. Эта переменная задаёт значение по умолчанию для параметра командной строки --inter-hunk-context.

Если эта переменная конфигурации установлена, то списки изменений создаются не с помощью внутренней реализации Git, а с помощью указанной команды. Эта команда может быть переопределена переменной окружения GIT_EXTERNAL_DIFF. Команда вызывается с параметрами, описанными в разделе «Утилита сравнения Git» в git[1]. Примечание: если вы хотите использовать стороннюю утилиту сравнения только для некоторого подмножества файлов, то вместо этой переменной вы, возможно, захотите использовать gitattributes[5].

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

Устанавливает значение по умолчанию для --ignore-submodules. Обратите внимание, что это влияет только на высокоуровневую команду git diff, но не на команды сравнения более низкого уровня, такие как git diff-files. Команды git checkout и git switch также уважают значение этой переменной при выводе списка незафиксированных изменений. Установка этой переменной в значение all отключает вывод сводки изменений в подмодулях, которую обычно показывают git commit и git status, если переменная конфигурации status.submoduleSummary установлена, если конечно это значение не переопределено в командной строке с помощью --ignore-submodules. На подкоманды git submodule эта переменная не влияет. По умолчанию она установлена в значение untracked, дабы любые неотслеживаемые подмодули игнорировались.

Если установлена, вместо стандартной пары префиксов a/ и b/ команда git diff будет использовать особую пару в зависимости от того, что сравнивается. Когда это включено, при выводе списка обратных изменений эти префиксы будут также идти в обратном порядке:

Если установлена, git diff не выводит никаких исходных или целевых префиксов.

Если установлена, git diff использует данное значение в качестве исходного префикса. По умолчанию: a/.

Если установлена, git diff использует данное значение в качестве целевого префикса. По умолчанию: b/.

Если установлена в true, git diff не показывает изменения вне текущего каталога и показывает пути относительно текущего каталога.

Файл, задающий в каком порядке должны идти файлы в списке изменений. См. подробности в описании параметра -O команды git-diff[1]. Если diff.orderFile является относительным путём, то он рассматривается как путь относительно корня рабочего каталога.

Количество файлов, которые следует рассматривать, когда поиск копирований/переименований переходит в свою «исчерпывающую» стадию; эквивалентно параметру -l команды git diff. Если переменная не установлена, то на данный момент значение по умолчанию равно 1000. Эта переменная не имеет эффекта, если поиск переименований отключён.

Должен ли Git пытаться найти переименования файлов и если да, то как именно. При значении false, обнаружение переименований отключено. При значении true, включён базовый поиск переименований. При значении copies или copy, Git также ищет копии. Значение по умолчанию установлено в true. Обратите внимание, что это влияет только на высокоуровневую команду git-diff[1] и git-log[1], но не на команды сравнения более низкого уровня, такие как git-diff-files[1].

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

Указывает формат, в котором отображаются различия в подмодулях. В формате short выводятся только имена коммитов в начале и конце диапазона. В формате log перечисляются коммиты в диапазоне, как в summary в git-submodule[1] . Формат diff показывает встроенный список изменений содержимого подмодуля. Значение по умолчанию: short.

Расширенное регулярное выражение POSIX, которое определяет, что является «словом», при построении пословного списка изменений. Последовательности символов, которые сопоставляются этому регулярному выражению, являются «cловами», все остальные символы считаются пробельными символами, которые могут быть проигнорированы.

Команда драйвера пользовательской утилиты сравнения. См. подробности в gitattributes[5].

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

Регулярное выражение, которое драйвер утилиты сравнения должен использовать для распознавания заголовка блока списка изменений. В качестве значения также может использоваться один из встроенных шаблонов. См. подробности в gitattributes[5].

Установите эту переменную конфигурации в значение true, чтобы драйвер утилиты сравнения обрабатывал файлы как двоичные. См. подробности в gitattributes[5].

Команда, которую драйвер утилиты сравнения должен вызвать для генерации текстовой версии файла. Результат преобразования используется для создания списка изменений в виде удобоваримом для чтения человеком. См. подробности в gitattributes[5].

Регулярное выражение, которое драйвер утилиты сравнения должен использовать для разделения слов в строке. См. подробности в gitattributes[5].

Установите эту переменную конфигурации в значение true, чтобы драйвер утилиты сравнения кэшировал результаты преобразования текста. См. подробности в gitattributes[5].

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

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

Выделять цветом ошибки в пробелах в контекстных (context), старых (old) или новых (new) строках списков изменений. Допустимо несколько значений, разделённых запятыми; none сбрасывает предыдущие значения, default сбрасывает список до new, а all — это сокращение для old,new,context. Ошибки в пробельных символах будут выделяться с помощью color.diff.whitespace. Параметр командной строки --ws-error-highlight=<тип> переопределяет эту переменную конфигурации.

Если в качестве значения этой переменной установлено допустимый <режим> или «true», перемещённые строки в списке изменений будут выделяться другим цветом. Подробности о допустимых режимах см. в описании параметра --color-moved команды git-diff[1]. Если в качестве значения установлено просто true, будет использован режим выделения по умолчанию. Если установлено false, перемещённые строки не выделяются.

Когда перемещённые строки выделяются цветом, например при установке diff.colorMoved, эта переменная конфигурации задаёт режим, в котором должный обрабатываться пробелы. Подробности о допустимых режимов см. в описании параметра --color-moved-ws команды git-diff[1].

Этот параметр управляет тем, будет ли git fetch (и базовое получение в git pull) рекурсивно получать данные в заполненные подмодули. Этот параметр может быть установлен либо в логическое значение, либо в on-demand. Установка в логическое значение изменяет поведение получения и извлечения на безусловную рекурсию в подмодули, если установлено true, или на отсутствие рекурсии вообще, если установлено false. При установке в on-demand получение и извлечение будут рекурсивно заходить в заполненный подмодуль только тогда, когда его суперпроект получает коммит, обновляющий ссылку подмодуля. По умолчанию on-demand или значение submodule.recurse, если оно установлено.

Если установлено в true, git-fetch-pack будет проверять все полученные объекты. Что именно проверяется, см. в transfer.fsckObjects. По умолчанию false. Если не установлено, вместо этого используется значение transfer.fsckObjects.

Действует как fsck.<msg-id>, но используется git-fetch-pack[1] вместо git-fsck[1]. Подробности см. в документации fsck.<msg-id>.

Действует как fsck.skipList, но используется git-fetch-pack[1] вместо git-fsck[1]. Подробности см. в документации fsck.skipList.

Если количество объектов, полученных по собственному протоколу Git, ниже этого предела, объекты будут распакованы в непакованные (loose) файлы объектов. Однако если количество полученных объектов равно или превышает этот предел, полученный pack-файл будет сохранён как pack-файл после добавления любых недостающих баз дельт. Сохранение pack-файла из отправки может ускорить выполнение операции отправки, особенно на медленных файловых системах. Если не установлено, вместо этого используется значение transfer.unpackLimit.

Если true, получение будет автоматически вести себя так, как если бы в командной строке была указана опция --prune. См. также remote.<имя>.prune и раздел ПОДЧИСТКА (PRUNING) в git-fetch[1].

Если true, получение будет автоматически вести себя так, как если бы спецификатор ссылки refs/tags/*:refs/tags/* был предоставлен при подчистке, если он ещё не установлен. Это позволяет установить как эту опцию, так и fetch.prune для поддержания сопоставления 1:1 с вышестоящими (upstream) ссылками. См. также remote.<имя>.pruneTags и раздел ПОДЧИСТКА (PRUNING) в git-fetch[1].

Если true, получение попытается обновить все доступные внешние репозитории. Это поведение можно переопределить, передав --no-all или явно указав один или несколько внешних репозиториев для получения. По умолчанию false.

Управляет тем, как печатается статус обновления ссылок. Допустимые значения: full и compact. Значение по умолчанию: full. Подробности см. в разделе OUTPUT в git-fetch[1].

Управляет тем, как отправляется информация о коммитах в локальном репозитории при согласовании содержимого pack-файла, который будет отправлен сервером. Установите consecutive, чтобы использовать алгоритм, который проходит по последовательным коммитам, проверяя каждый. Установите skipping, чтобы использовать алгоритм, который пропускает коммиты в попытке сойтись быстрее, но может привести к созданию pack-файла большего, чем необходимо; или установите noop, чтобы вообще не отправлять никакую информацию, что почти наверняка приведёт к созданию pack-файла большего, чем необходимо, но пропустит этап согласования. Установите default, чтобы переопределить ранее сделанные настройки и использовать поведение по умолчанию. Обычно по умолчанию используется consecutive, но если feature.experimental равно true, то по умолчанию используется skipping. Неизвестные значения приведут к ошибке git fetch.

Установите в false, чтобы включить --no-show-forced-updates в командах git-fetch[1] и git-pull[1]. По умолчанию true.

Указывает максимальное количество операций получения, выполняемых параллельно за раз (подмодули или внешние репозитории, когда действует опция --multiple команды git-fetch[1]).

Установите true, чтобы записывать граф коммитов после каждой команды git fetch, которая загружает pack-файл из внешнего репозитория. При использовании опции --split большинство выполнений создадут очень маленький файл графа коммитов поверх существующего(их) файла(ов) графа коммитов. Иногда эти файлы будут сливаться, и запись может занять больше времени. Наличие обновлённого файла графа коммитов повышает производительность многих команд Git, включая git merge-base, git push -f и git log --graph. По умолчанию false.

Это значение хранит URI для загрузки данных объектов Git из bundle URI перед выполнением инкрементального получения с исходного Git-сервера. Это похоже на то, как ведёт себя опция --bundle-uri в git-clone[1]. git clone --bundle-uri установит значение fetch.bundleURI, если предоставленный bundle URI содержит список пакетов, организованный для инкрементальных получений.

При использовании fetch.bundleURI для инкрементального получения из списка пакетов, использующего эвристику «creationToken», это значение конфигурации хранит максимальное значение creationToken загруженных пакетов. Это значение используется для предотвращения загрузки пакетов в будущем, если объявленный creationToken не строго больше этого значения.

Задаёт каталог, из которого будут копироваться шаблоны. (See the "TEMPLATE DIRECTORY" section of git-init[1].)

Позволяет переопределить имя ветки по умолчанию, которое, например, используется при инициализации нового репозитория.

Позволяет переопределить формат объектов по умолчанию для новых репозиториев. См. --object-format= в git-init[1]. Как этот параметр командной строки, так и переменная среды GIT_DEFAULT_HASH являются более приоритетными, чем данная переменная конфигурации.

Позволяет переопределить формат хранения ссылок по умолчанию для новых репозиториев. См. --ref-format= в git-init[1]. Как этот параметр командной строки, так и переменная среды GIT_DEFAULT_REF_FORMAT являются более приоритетными, чем данная переменная конфигурации.

Логическое значение, указывающее, должны ли git init и git clone автоматически устанавливать extensions.submodulePathConfig в true. Это позволяет всем новым репозиториям автоматически использовать расширение пути подмодуля. По умолчанию, если не задано, равно false.

Если true, заставить git-log[1], git-show[1] и git-whatchanged[1] подразумевать --abbrev-commit. Вы можете переопределить эту опцию с помощью --no-abbrev-commit.

Установить режим даты-времени по умолчанию для команды log. Установка значения для log.date аналогична использованию опции --date в git log. Подробности см. в git-log[1].

Выводить имена ссылок любых коммитов, показываемых командой log. Возможные значения:

По умолчанию git log показывает оформление только для определённых известных пространств имён ссылок. Если указано all, то показывать все ссылки как оформление.

Исключить указанные шаблоны из украшений журнала. Это похоже на опцию командной строки --decorate-refs-exclude, но опция конфигурации может быть переопределена опцией --decorate-refs.

Устанавливает формат сравнения, используемый при указании --diff-merges=on; подробности см. в --diff-merges в git-log[1]. По умолчанию separate.

Если true, git log будет вести себя так, как если бы была использована опция --follow, когда указан один <путь>. Это имеет те же ограничения, что и --follow, т.е. его нельзя использовать для отслеживания нескольких файлов, и он плохо работает с нелинейной историей.

Список цветов, разделённых запятыми, которые можно использовать для рисования линий истории в git log --graph.

Если true, начальный коммит будет показан как большое событие создания. Это эквивалентно сравнению с пустым деревом. Инструменты, такие как git-log[1] или git-whatchanged[1], которые обычно скрывают корневой коммит, теперь будут его показывать. По умолчанию true.

Если true, заставляет git-log[1], git-show[1] и git-whatchanged[1] подразумевать --show-signature.

Если true, заставляет git-log[1], git-show[1] и git-whatchanged[1] подразумевать --use-mailmap, в противном случае подразумевать --no-use-mailmap. По умолчанию true.

Определяет стиль, в котором конфликтные блоки записываются в файлы рабочего дерева при слиянии. По умолчанию используется «merge», который показывает маркер конфликта <<<<<<<, изменения одной стороны, маркер =======, изменения другой стороны и затем маркер >>>>>>>. Альтернативный стиль «diff3» добавляет маркер ||||||| и исходный текст перед маркером =======. Стиль «merge» обычно создаёт меньшие области конфликта, чем «diff3», как из-за исключения исходного текста, так и потому, что когда подмножество строк совпадает с обеих сторон, они просто выносятся из области конфликта. Ещё один альтернативный стиль, «zdiff3», похож на «diff3», но удаляет совпадающие строки с обеих сторон из области конфликта, когда эти совпадающие строки появляются ближе к началу или концу области конфликта.

Если merge вызывается без аргумента коммита, выполняется слияние вышестоящих веток, настроенных для текущей ветки, с использованием их последних наблюдаемых значений, сохранённых в их удалённых отслеживающих ветках. Используются значения branch.<текущая ветка>.merge, которые называют ветки в удалённом репозитории, указанном в branch.<текущая ветка>.remote, а затем они отображаются через remote.<удалённый>.fetch в соответствующие удалённые отслеживающие ветки, и концы этих отслеживающих веток сливаются. По умолчанию true.

По умолчанию Git не создаёт дополнительный коммит слияния при слиянии коммита, являющегося потомком текущего коммита. Вместо этого конец текущей ветки перемещается вперёд (fast-forward). При установке в false эта переменная указывает Git создать дополнительный коммит слияния в таком случае (эквивалентно передаче опции --no-ff из командной строки). При установке в only разрешены только такие быстрые слияния (эквивалентно передаче параметра --ff-only из командной строки).

Если true, это эквивалентно опции командной строки --verify-signatures. Подробности см. в git-merge[1].

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

Помимо имён веток, заполнять сообщение журнала не более чем указанным количеством однострочных описаний из фактических коммитов, которые сливаются. По умолчанию false, а true является синонимом 20.

Добавляя glob, соответствующий именам веток интеграции, в эту многозначную конфигурационную переменную, стандартное сообщение о слиянии, вычисляемое для слияний в эти ветки интеграции, будет опускать "into <имя-ветки>" из своего заголовка.

Количество файлов для рассмотрения в исчерпывающей части обнаружения переименований во время слияния. Если не указано, по умолчанию используется значение diff.renameLimit. Если не указаны ни merge.renameLimit, ни diff.renameLimit, в настоящее время по умолчанию используется 7000. Этот параметр не действует, если обнаружение переименований отключено.

Должен ли Git находить переименования. При значении false обнаружение переименований отключено. При значении true включено базовое обнаружение переименований. По умолчанию используется значение diff.renames.

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

Сообщает Git, что каноническое представление файлов в репозитории со временем изменилось (например, ранние коммиты записывают текстовые файлы с окончаниями строк CRLF, а более поздние используют LF). В таком репозитории для каждого файла, требующего трёхстороннего слияния содержимого, Git может преобразовать данные, записанные в коммитах, в каноническую форму перед выполнением слияния, чтобы уменьшить количество ненужных конфликтов. Для получения дополнительной информации см. раздел «Слияние веток с различными атрибутами checkin/checkout» в gitattributes[5].

Определяет, что печатать (если вообще что-либо) между ORIG_HEAD и результатом слияния в конце процесса слияния. Возможные значения:

При значении true автоматически создаёт временную запись stash перед началом операции и применяет её после завершения операции. Это позволяет выполнять слияние на грязном рабочем дереве. Однако используйте с осторожностью: финальное применение stash после успешного слияния может привести к непростым конфликтам. Эту опцию можно переопределить с помощью опций --no-autostash и --autostash команды git-merge[1]. По умолчанию false.

Управляет тем, какой инструмент слияния используется git-mergetool[1]. Список ниже показывает допустимые встроенные значения. Любое другое значение трактуется как пользовательский инструмент слияния и требует определения соответствующей переменной mergetool.<инструмент>.cmd.

Управляет тем, какой инструмент слияния используется git-mergetool[1] при указании флага -g/--gui. Список ниже показывает допустимые встроенные значения. Любое другое значение трактуется как пользовательский инструмент слияния и требует определения соответствующей переменной mergetool.<guitool>.cmd.

Управляет объёмом вывода, показываемого рекурсивной стратегией слияния. Уровень 0 не выводит ничего, кроме финального сообщения об ошибке, если обнаружены конфликты. Уровень 1 выводит только конфликты, 2 — конфликты и изменения файлов. Уровень 5 и выше выводит отладочную информацию. По умолчанию используется уровень 2. Может быть переопределено переменной окружения GIT_MERGE_VERBOSITY.

Определяет человекопонятное имя для пользовательского низкоуровневого драйвера слияния. Подробности см. в gitattributes[5].

Определяет команду, реализующую пользовательский низкоуровневый драйвер слияния. Подробности см. в gitattributes[5].

Указывает низкоуровневый драйвер слияния, который будет использоваться при выполнении внутреннего слияния между общими предками. Подробности см. в gitattributes[5].

Переопределить путь для указанного инструмента. Это полезно, если ваш инструмент не находится в $PATH.

Указывает команду для вызова указанного инструмента слияния. Указанная команда выполняется в оболочке со следующими доступными переменными: BASE — имя временного файла, содержащего общую базу файлов для слияния, если доступно; LOCAL — имя временного файла, содержащего содержимое файла в текущей ветке; REMOTE — имя временного файла, содержащего содержимое файла из ветки, с которой выполняется слияние; MERGED содержит имя файла, в который инструмент слияния должен записать результаты успешного слияния.

Позволяет пользователю переопределить глобальное значение mergetool.hideResolved для конкретного инструмента. Полное описание см. в mergetool.hideResolved.

Для пользовательской команды слияния укажите, можно ли использовать код завершения команды слияния для определения успешности слияния. Если это не установлено в true, проверяется временная метка целевого файла слияния, и предполагается, что слияние прошло успешно, если файл был обновлён; в противном случае пользователю предлагается указать успешность слияния.

Старые версии meld не поддерживают опцию --output. Git попытается определить, поддерживает ли meld --output, проверив вывод meld --help. Настройка mergetool.meld.hasOutput заставит Git пропустить эти проверки и вместо этого использовать настроенное значение. Установка mergetool.meld.hasOutput в true указывает Git безоговорочно использовать опцию --output, а false избегает использования --output.

Когда указан --auto-merge, meld автоматически сливает все неконфликтующие части, выделяет конфликтующие части и ожидает решения пользователя. Установка mergetool.meld.useAutoMerge в true указывает Git безоговорочно использовать опцию --auto-merge с meld. Установка этого значения в auto заставляет git определять, поддерживается ли --auto-merge, и использовать --auto-merge только когда доступно. Значение false полностью избегает использования --auto-merge и является значением по умолчанию.

Настроить макет разделённого окна для <варианта> vimdiff, который может быть vimdiff, nvimdiff, gvimdiff. При запуске git mergetool с --tool=<вариант> (или без --tool, если merge.tool настроен как <вариант>), Git обратится к mergetool.<вариант>.layout, чтобы определить макет инструмента. Если конфигурация, специфичная для варианта, недоступна, используется макет vimdiff в качестве запасного варианта. Если и он недоступен, будет использоваться макет по умолчанию с 4 окнами. Чтобы настроить макет, см. «ПОДСКАЗКИ ПО ВНУТРЕННИМ МЕХАНИЗМАМ» раздел в git-mergetool[1].

Во время слияния Git автоматически разрешает как можно больше конфликтов и записывает файл $MERGED, содержащий маркеры конфликтов вокруг любых конфликтов, которые он не может разрешить; $LOCAL и $REMOTE обычно являются версиями файла до разрешения конфликтов Git. Этот флаг приводит к перезаписи $LOCAL и $REMOTE, так что инструменту слияния представляются только неразрешённые конфликты. Может быть настроен для каждого инструмента через переменную конфигурации mergetool.<инструмент>.hideResolved. По умолчанию false.

После выполнения слияния исходный файл с маркерами конфликтов может быть сохранён как файл с расширением .orig. Если эта переменная установлена в false, этот файл не сохраняется. По умолчанию true (т.е. сохранять резервные копии).

При вызове пользовательского инструмента слияния Git использует набор временных файлов для передачи инструменту. Если инструмент возвращает ошибку и эта переменная установлена в true, эти временные файлы будут сохранены; в противном случае они будут удалены после завершения работы инструмента. По умолчанию false.

По умолчанию Git записывает временные версии BASE, LOCAL и REMOTE конфликтующих файлов в рабочем каталоге. При установке true Git попытается использовать для этих файлов временный каталог. По умолчанию false.

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

Установите true, чтобы использовать merge.guitool по умолчанию (эквивалентно указанию аргумента --gui), или auto, чтобы выбирать merge.guitool или merge.tool в зависимости от наличия значения переменной среды DISPLAY. По умолчанию false, когда аргумент --gui должен быть предоставлен явно для использования merge.guitool.

Какую стратегию слияния выбирать по умолчанию при разрешении конфликтов заметок. Должна быть одной из manual, ours, theirs, union или cat_sort_uniq. По умолчанию manual. Дополнительную информацию о каждой стратегии см. в разделе «СТРАТЕГИИ СЛИЯНИЯ ЗАМЕТОК» в git-notes[1].

Какую стратегию слияния выбрать при выполнении слияния заметок в refs/notes/<имя>. Это переопределяет более общую notes.mergeStrategy. Дополнительную информацию о доступных стратегиях см. в разделе «СТРАТЕГИИ СЛИЯНИЯ ЗАМЕТОК» в git-notes[1].

Какая ссылка (или ссылки, если это glob-шаблон или указано более одного раза), в дополнение к умолчанию, заданному core.notesRef или GIT_NOTES_REF, должна использоваться для чтения заметок при показе сообщений коммитов с помощью семейства команд git log.

При перезаписи коммитов с помощью <команда> (в настоящее время amend или rebase), если эта переменная имеет значение false, git не будет копировать заметки из исходного коммита в перезаписанный. По умолчанию true. См. также notes.rewriteRef ниже.

При копировании заметок во время перезаписи (см. параметр notes.rewrite.<команда>) определяет, что делать, если у целевого коммита уже есть заметка. Должно быть одним из overwrite, concatenate, cat_sort_uniq или ignore. По умолчанию concatenate.

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

Если установлено в true, подразумевать --set-upstream при отправке по умолчанию, когда для текущей ветки не существует вышестоящего (upstream) отслеживания; этот параметр действует с опциями push.default simple, upstream и current. Это полезно, если по умолчанию вы хотите, чтобы новые ветки отправлялись во внешний репозиторий по умолчанию (как поведение push.default=current) и вы также хотите, чтобы было установлено вышестоящее отслеживание. Наиболее вероятные рабочие процессы, которые выиграют от этого параметра, — это simple централизованные рабочие процессы, где ожидается, что все ветки будут иметь одинаковые имена во внешнем репозитории.

Определяет действие, которое должно выполняться git push, если не указан спецификатор ссылки (будь то из командной строки, конфигурации или другого места). Разные значения хорошо подходят для конкретных рабочих процессов; например, в чисто централизованном рабочем процессе (т.е. источник получения равен цели отправки), upstream, вероятно, то, что вам нужно. Возможные значения:

Если установлено в true, включить опцию --follow-tags по умолчанию. Вы можете переопределить эту конфигурацию во время отправки, указав --no-follow-tags.

Может быть установлен в логическое значение или в строку if-asked. Значение true заставляет все отправки подписываться с помощью GPG, как если бы --signed был передан в git-push[1]. Строка if-asked заставляет отправки подписываться, если сервер это поддерживает, как если бы --signed=if-asked был передан в git push. Значение false может переопределить значение из конфигурационного файла с более низким приоритетом. Явный флаг командной строки всегда переопределяет этот параметр конфигурации.

Если аргумент --push-option=<параметр> не задан в командной строке, git push ведёт себя так, как если бы каждый <параметр> этой переменной был задан как --push-option=<параметр>.

Пример:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

В результате останется только b (a и c будут очищены).

Может быть check, on-demand, only или no, с тем же поведением, что и у push --recurse-submodules. Если не установлено, по умолчанию используется no, если только не установлен submodule.recurse (в этом случае значение true означает on-demand).

Если установлено в true, это эквивалентно указанию --force-if-includes в качестве параметра для git-push[1] в командной строке. Добавление --no-force-if-includes во время отправки переопределяет этот параметр конфигурации.

Если установлено в true, пытаться уменьшить размер отправляемого pack-файла с помощью раундов согласования, в которых клиент и сервер пытаются найти общие коммиты. Если false, Git будет полагаться исключительно на объявление ссылок сервера для поиска общих коммитов.

Если установлено в false, отключить использование битовых карт для git push, даже если pack.useBitmaps имеет значение true, не препятствуя использованию битовых карт другими операциями git. По умолчанию true.

Внутренний механизм по умолчанию для перемещения (rebase). Возможные варианты: apply или merge. В будущем, если внутренний механизм слияния (merge backend) получит все оставшиеся возможности внутреннего механизма наложения (apply backend), этот параметр может перестать использоваться.

Показывать ли diffstat того, что изменилось выше по течению (upstream) с момента последнего перемещения. По умолчанию false.

Если установлено в true, включить параметр --autosquash команды git-rebase[1] по умолчанию для интерактивного режима. Это можно переопределить с помощью параметра --no-autosquash.

Если установлено в true, автоматически создаёт временную запись в тайнике (stash) перед началом операции и применяет её после завершения операции. Это означает, что вы можете выполнять перемещение на грязном рабочем каталоге. Однако используйте с осторожностью: финальное применение тайника после успешного перемещения может привести к нетривиальным конфликтам. Этот параметр может быть переопределён параметрами --no-autostash и --autostash команды git-rebase[1]. По умолчанию false.

Если установлено в true, включить параметр --update-refs по умолчанию.

Если установлено в «warn», git rebase -i выведет предупреждение, если некоторые коммиты удалены (например, строка была удалена), однако перемещение всё равно продолжится. Если установлено в «error», он выведет предыдущее предупреждение и остановит перемещение; затем можно использовать git rebase --edit-todo для исправления ошибки. Если установлено в «ignore», никакая проверка не выполняется. Чтобы отбросить коммит без предупреждения или ошибки, используйте команду drop в списке задач. По умолчанию «ignore».

Строка формата, как указано в git-log[1], используемая для списка задач во время интерактивного перемещения. К формату автоматически будет добавлен хеш коммита в начале.

Если установлено в true, git rebase будет использовать сокращённые имена команд в списке задач, что приведёт к чему-то вроде этого:

	p deadbee Однострочное описание коммита
	p fa1afe1 Однострочное описание следующего коммита
	...

	pick deadbee Однострочное описание коммита
	pick fa1afe1 Однострочное описание следующего коммита
	...

Автоматически перепланировать команды exec, которые завершились сбоем. Это имеет смысл только в интерактивном режиме (или когда была предоставлена опция --exec). Это то же самое, что и указание опции --reschedule-failed-exec.

Если установлено в false, установить опцию --no-fork-point по умолчанию.

Следует ли и как устанавливать опцию --rebase-merges по умолчанию. Может быть rebase-cousins, no-rebase-cousins или логическим значением. Установка в true или в no-rebase-cousins эквивалентна --rebase-merges=no-rebase-cousins, установка в rebase-cousins эквивалентна --rebase-merges=rebase-cousins, а установка в false эквивалентна --no-rebase-merges. Передача --rebase-merges в командной строке, с аргументом или без, переопределяет любую конфигурацию rebase.rebaseMerges.

При создании имён меток из тем коммитов усекать имена до этой длины. По умолчанию имена усекаются до значения немного меньшего, чем NAME_MAX (чтобы разрешить, например, запись файлов .lock для соответствующих непакованных (loose) ссылок).

Текстовый редактор, используемый git rebase -i для редактирования файла инструкций перемещения. Значение должно интерпретироваться оболочкой при его использовании. Может быть переопределено переменной среды GIT_SEQUENCE_EDITOR. Если не настроено, вместо него используется редактор сообщений коммитов по умолчанию.

Если установлено в true, git stash apply и git stash pop будут вести себя так, как будто был указан --index. По умолчанию false. См. описания в git-stash[1].

Если установлено в true, команда git stash show будет показывать неотслеживаемые файлы записи в тайнике (stash). По умолчанию false. See the description of the 'show' command in git-stash[1].

Если установлено в true, команда git stash show без параметра будет показывать запись в тайнике (stash) в форме изменения (патча). По умолчанию false. See the description of the 'show' command in git-stash[1].

Если установлено в true, команда git stash show без параметра будет показывать diffstat записи в тайнике (stash). По умолчанию true. See the description of the 'show' command in git-stash[1].

Логическое значение, указывающее, должны ли создаваемые аннотированные метки подписываться с помощью GPG. Если в командной строке указан --annotate, он имеет приоритет над этой опцией.

Эта переменная управляет порядком сортировки меток при отображении git-tag[1]. Если не указана опция --sort=<значение>, значение этой переменной будет использоваться по умолчанию.

Логическое значение, указывающее, должны ли все метки подписываться с помощью GPG. Использование этой опции при выполнении в автоматизированном скрипте может привести к подписанию большого количества меток. Поэтому удобно использовать агент, чтобы избежать многократного ввода вашей GPG-фразы. Обратите внимание, что эта опция не влияет на поведение подписания меток, включённое опциями -u <id-ключа> или --local-user=<id-ключа>.

Если ветка не указана и не используются ни -b, ни -B, ни --detach, то git worktree add по умолчанию создаёт новую ветку из HEAD. Если worktree.guessRemote установлено в true, worktree add пытается найти отслеживаемую внешнюю ветку, имя которой однозначно соответствует имени новой ветки. Если такая ветка существует, она переключается (checkout) и устанавливается как «вышестоящая» (upstream) для новой ветки. Если такого соответствия найти не удаётся, возвращается к созданию новой ветки из текущего HEAD.

Связывать рабочие копии (worktrees), используя относительные пути (когда «true») или абсолютные пути (когда «false»). Это особенно полезно для конфигураций, где репозиторий и рабочие копии могут перемещаться между разными местами или средами. По умолчанию «false».