Git

git-config last updated in 2.51.1

НАЗВА

git-config - Отримання та встановлення параметрів репозиторію або глобальних параметрів

СИНОПСИС

git config list [<file-option>] [<display-option>] [--includes]
git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
git config set [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
git config unset [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
git config rename-section [<file-option>] <old-name> <new-name>
git config remove-section [<file-option>] <name>
git config edit [<file-option>]
git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]

ОПИС

За допомогою цієї команди ви можете запитувати/встановлювати/замінювати/скидати параметри. Назва насправді є секцією та ключем, розділеними крапкою, а значення буде екрановано.

Multiple lines can be added to an option by using the --append option. If you want to update or unset an option which can occur on multiple lines, --value=<pattern> (which is an extended regular expression, unless the --fixed-value option is given) needs to be given. Only the existing values that match the pattern are updated or unset. If you want to handle the lines that do not match the pattern, just prepend a single exclamation mark in front (see also ПРИКЛАДИ), but note that this only works when the --fixed-value option is not in use.

Опція --type=<тип> вказує git config забезпечити канонізацію вхідних та вихідних значень для заданого <тип>. Якщо --type=<тип> не вказано, канонізація не виконуватиметься. Викликаючі сторони можуть скинути існуючий специфікатор --type за допомогою --no-type.

Під час читання значення за замовчуванням зчитуються із системних, глобальних та локальних файлів конфігурації репозиторію, а опції --system, --global, --local, --worktree та --file <ім'я файлу> можна використовувати, щоб вказати команді читати лише з цього місця (див. ФАЙЛИ).

Під час запису нове значення за замовчуванням записується до локального файлу конфігурації репозиторію, а опції --system, --global, --worktree, --file <ім'я файлу> можна використовувати, щоб вказати команді записувати до цього місця (можна сказати --local, але це значення за замовчуванням).

Ця команда завершиться невдачею з ненульовим статусом у разі помилки. Деякі коди виходу:

Розділ або ключ недійсний (ret=1),
не було вказано жодного розділу чи назви (ret=2),
конфігураційний файл недійсний (ret=3),
конфігураційний файл неможливо записати (ret=4),
ви намагаєтеся скасувати значення параметра, якого не існує (ret=5),
ви намагаєтеся встановити/скасувати опцію, для якої збігається кілька рядків (ret=5), або
ви намагаєтеся використати недійсний регулярний вираз (ret=6).

У разі успіху команда повертає код виходу 0.

Список усіх доступних змінних конфігурації можна отримати за допомогою команди git help --config.

КОМАНДИ

list: Перелічіть усі змінні, встановлені у конфігураційному файлі, разом з їхніми значеннями.
get: Видає значення вказаного ключа. Якщо ключ присутній кілька разів у конфігурації, видає останнє значення. Якщо вказано --all, видає всі значення, пов’язані з ключем. Повертає код помилки 1, якщо ключ відсутній.
set: Встановити значення для одного або кількох параметрів конфігурації. За замовчуванням ця команда відмовляється записувати багатозначні параметри конфігурації. Передача --all замінить усі багатозначні параметри конфігурації новим значенням, тоді як --value= замінить усі параметри конфігурації, значення яких відповідають заданому шаблону.
unset: Скасувати значення для одного або кількох параметрів конфігурації. За замовчуванням ця команда відмовляється скидати значення багатозначних ключів. Передача --all скине всі багатозначні параметри конфігурації, тоді як --value скине всі параметри конфігурації, значення яких відповідають заданому шаблону.
rename-section: Перейменуйте заданий розділ на нове ім’я.
remove-section: Видаліть вказаний розділ з файлу конфігурації.
edit: Відкриває редактор для зміни вказаного конфігураційного файлу; --system, --global, --local (за замовчуванням), --worktree або --file <файл-конфігурації>.

ОПЦІЇ

--replace-all

За замовчуванням замінюється максимум один рядок. Це замінює всі рядки, що відповідають ключу (і, за бажанням, --value=<шаблон>).

--append

Додає новий рядок до опції, не змінюючи жодних існуючих значень. Це те саме, що й надання --value=^$ у set.

--comment <повідомлення>

Додайте коментар у кінці нових або змінених рядків.

Якщо _<повідомлення>_ починається з одного або кількох пробілів, за якими йде "#", воно використовується як є. Якщо воно починається з "#", перед його використанням додається пробіл. В іншому випадку до нього додається рядок "#" (пробіл, за яким йде хеш, а потім пробіл). Отриманий рядок розміщується одразу після значення, визначеного для змінної. _<повідомлення>_ не повинно містити символів переведення рядка (багаторядкові коментарі не дозволені).

--all

За допомогою функції get повернути всі значення для багатозначного ключа.

--regexp

За допомогою команди get інтерпретувати назву як регулярний вираз. Зіставлення регулярних виразів наразі враховує регістр і виконується з канонізованою версією ключа, в якій назви розділів і змінних пишуться з нижнього регістру, а назви підрозділів – ні.

--url=<URL>

Якщо як <section>.<key> задано двокомпонентний <name>, повертається значення для <section>.<URL>.<key>, частина <URL> якого найкраще відповідає заданій URL-адресі (якщо такого ключа не існує, значення для <section>.<key> використовується як резервний варіант). Якщо як ім’я задано лише <section>, це робиться для всіх ключів у розділі та перераховується їх. Повертає код помилки 1, якщо значення не знайдено.

--global

Щодо параметрів запису: записувати у глобальний файл ~/.gitconfig, а не в репозиторій .git/config, записувати у файл $XDG_CONFIG_HOME/git/config, якщо цей файл існує, а файл ~/.gitconfig ні.

Щодо параметрів читання: читати лише з глобального ~/.gitconfig та з $XDG_CONFIG_HOME/git/config, а не з усіх доступних файлів.

Див. також ФАЙЛИ.

--system

Щодо параметрів запису: записуйте до системного файлу $(prefix)/etc/gitconfig, а не до репозиторію .git/config.

Щодо параметрів читання: читати лише з загальносистемного $(prefix)/etc/gitconfig, а не з усіх доступних файлів.

Див. також ФАЙЛИ.

--local

Щодо параметрів запису: запишіть у файл репозиторію .git/config. Це поведінка за замовчуванням.

Щодо параметрів читання: читати лише з репозиторію .git/config, а не з усіх доступних файлів.

Див. також ФАЙЛИ.

--worktree

Подібно до --local, за винятком того, що $GIT_DIR/config.worktree зчитується або записується, якщо extensions.worktreeConfig увімкнено. Якщо ні, то це те саме, що й --local. Зверніть увагу, що $GIT_DIR дорівнює $GIT_COMMON_DIR для основного робочого дерева, але має вигляд $GIT_DIR/worktrees/<id>/ для інших робочих дерев. Див. git-worktree[1], щоб дізнатися, як увімкнути extensions.worktreeConfig.

-f <config-file>

--file <config-file>

Щодо параметрів запису: записуйте у вказаний файл, а не в репозиторій .git/config.

Щодо параметрів читання: читати лише з вказаного файлу, а не з усіх доступних файлів.

Див. також ФАЙЛИ.

--blob <blob>

Подібно до --file, але замість файлу використовується заданий блоб. Наприклад, ви можете використовувати master:.gitmodules для зчитування значень з файлу .gitmodules у гілці master. Див. розділ "ВИЗНАЧЕННЯ РЕВІЗІЙ" у gitrevisions[7] для повнішого списку способів написання імен блобів.

--value=<pattern>

--no-value

З get, set та unset, зіставлення здійснюється лише з <шаблон>. Шаблон є розширеним регулярним виразом, якщо не вказано --fixed-value.

Використовуйте --no-value, щоб скасувати встановлення <шаблон>.

--fixed-value

При використанні з --value=<шаблон>, <шаблон> розглядайте як точний рядок, а не як регулярний вираз. Це обмежить пари ім’я/значення, які збігаються, лише тими, де значення точно дорівнює <шаблон>.

--type <type>

Команда «git config» гарантуватиме, що будь-які вхідні або вихідні дані є коректними згідно з заданими обмеженнями типу, та канонізуватиме вихідні значення в канонічну форму <type>.

Дійсні <type> включають:

bool: канонізувати значення true, yes, on та додатні числа як "true", а значення false, no, off та 0 як "false".
int: канонізувати значення як прості десяткові числа. Додатковий суфікс k, m або g призведе до множення значення на 1024, 1048576 або 1073741824 під час введення.
bool-or-int: канонізувати відповідно до bool або int, як описано вище.
path: канонізувати, розширюючи початковий символ ~ до значення $HOME та ~user до домашнього каталогу для зазначеного користувача. Цей специфікатор не впливає на встановлення значення (але ви можете використати git config section.variable ~/ з командного рядка, щоб ваша оболонка виконала розширення).
expiry-date: канонізувати шляхом перетворення фіксованого або відносного рядка дати на позначку часу. Цей специфікатор не впливає на встановлення значення.
колір: Під час отримання значення канонізувати шляхом перетворення на керуючу послідовність кольору ANSI. Під час встановлення значення виконується перевірка на бездоганність, щоб переконатися, що задане значення можна канонізувати як колір ANSI, але воно записується як є.

--bool

--int

--bool-or-int

--path

--expiry-date

Історичні опції вибору специфікатора типу. Замість цього надайте перевагу --type (див. вище).

--no-type

Скасовує попередньо встановлений специфікатор типу (якщо такий був раніше встановлений). Ця опція вимагає, щоб git config не канонізував отриману змінну. --no-type не має ефекту без --type=<тип> або --<тип>.

-z

--null

Для всіх опцій, що виводять значення та/або ключі, завжди завершуйте значення символом null (замість символу нового рядка). Використовуйте символ нового рядка як роздільник між ключем і значенням. Це дозволяє безпечно обробляти вивід, не плутаючись, наприклад, зі значеннями, що містять розриви рядків.

--name-only

Виведіть лише назви змінних конфігурації для list або get.

--show-names

--no-show-names

За допомогою get відображаються ключі конфігурації на додаток до їхніх значень. Значення за замовчуванням — --no-show-names, якщо не вказано --url і в <назва> немає підрозділів.

--show-origin

Доповніть вивід усіх запитуваних параметрів конфігурації типом походження (файл, стандартний ввід, блоб, командний рядок) та фактичним походженням (шлях до файлу конфігурації, посилання або ідентифікатор блобу, якщо застосовно).

--show-scope

Подібно до --show-origin тим, що він доповнює вивід усіх запитуваних параметрів конфігурації областю дії цього значення (робоче дерево, локальний, глобальний, системний, команда).

--get-colorbool <name> [<stdout-is-tty>]

Знайдіть налаштування кольору для <name> (наприклад, color.diff) та виведіть "true" або "false". <stdout-is-tty> має бути або "true", або "false", і враховується, коли конфігурація вказує на "auto". Якщо <stdout-is-tty> відсутній, то перевіряється стандартний вивід самої команди та завершується зі статусом 0, якщо має використовуватися колір, або зі статусом 1 в іншому випадку. Коли налаштування кольору для name не визначено, команда використовує color.ui як резервний варіант.

--[no-]includes

Враховуйте директиви include.* у конфігураційних файлах під час пошуку значень. За замовчуванням встановлено значення off, коли вказано певний файл (наприклад, за допомогою --file, --global тощо), та on під час пошуку у всіх конфігураційних файлах.

--default <value>

Якщо використовується функція get, а запитувана змінна не знайдена, поводьтеся так, ніби <value> — це значення, призначене цій змінній.

ЗАСТАРІЛІ РЕЖИМИ

Наступні режими застаріли на користь підкоманд. Рекомендується перейти на новий синтаксис.

git config <name>: Замінено на git config get <name>.
git config <name> <value> [<value-pattern>]: Замінено на git config set [--value=<pattern>] <name> <value>.
-l
--list: Замінено на git config list.
--get <name> [<value-pattern>]: Замінено на git config get [--value=<pattern>] <name>.
--get-all <name> [<value-pattern>]: Замінено на git config get [--value=<pattern>] --all <name>.
--get-regexp <ім’я-регулярний вираз>: Замінено на git config get --all --show-names --regexp <name-regexp>.
--get-urlmatch <name> <URL>: Замінено на git config get --all --show-names --url=<URL> <name>.
--get-color <name> [<default>]: Замінено на git config get --type=color [--default=<default>] <name>.
--add <name> <value>: Замінено на git config set --append <name> <value>.
--unset <name> [<value-pattern>]: Замінено на git config unset [--value=<pattern>] <name>.
--unset-all <name> [<value-pattern>]: Замінено на git config unset [--value=<pattern>] --all <name>.
--rename-section <old-name> <new-name>: Замінено на git config rename-section <old-name> <new-name>.
--remove-section <ім’я>: Замінено на git config remove-section <name>.
-e
--edit: Замінено на git config edit.

КОНФІГУРАЦІЯ

pager.config враховується лише під час виведення списку конфігурації, тобто під час використання list або get, які можуть повертати кілька результатів. За замовчуванням використовується пейджер.

ФАЙЛИ

За замовчуванням, git config зчитуватиме параметри конфігурації з кількох файлів:

$(prefix)/etc/gitconfig: Загальносистемний файл конфігурації.
$XDG_CONFIG_HOME/git/config
~/.gitconfig: Файли конфігурації, специфічні для користувача. Коли змінна середовища XDG_CONFIG_HOME не встановлена або порожня, $HOME/.config/ використовується як $XDG_CONFIG_HOME.

Їх також називають «глобальними» файлами конфігурації. Якщо обидва файли існують, вони зчитуються в порядку, зазначеному вище.
$GIT_DIR/config: Файл конфігурації, специфічний для репозиторію.
$GIT_DIR/config.worktree: Це необов’язково та пошук виконується лише тоді, коли extensions.worktreeConfig присутній у $GIT_DIR/config.

Ви також можете надати додаткові параметри конфігурації під час виконання будь-якої команди git, використовуючи опцію -c. Див. git[1] для отримання детальної інформації.

Опції будуть зчитуватися з усіх доступних файлів. Якщо глобальні або системні файли конфігурації відсутні або нечитабельні, вони будуть проігноровані. Якщо файл конфігурації репозиторію відсутній або нечитабельний, «git config» завершиться з ненульовим кодом помилки. Повідомлення про помилку виводиться, якщо файл нечитабельний, але не якщо він відсутній.

Файли зчитуються в порядку, зазначеному вище, причому останнє знайдене значення має пріоритет над значеннями, зчитаними раніше. Якщо взято кілька значень, то будуть використані всі значення ключа з усіх файлів.

За замовчуванням, параметри записуються лише до конфігураційного файлу репозиторію. Зверніть увагу, що це також впливає на параметри, такі як set та unset. git config змінюватиме лише один файл за раз.

Ви можете обмежити джерела конфігурації, з яких зчитуються або куди записуються дані, вказавши шлях до файлу за допомогою опції --file або вказавши область конфігурації за допомогою --system, --global, --local або --worktree. Докладніше див. у ОПЦІЇ вище.

ПРИЛАДИ

Кожне джерело конфігурації потрапляє в певну область конфігурації. Ці області дії:

system: $(prefix)/etc/gitconfig
global: $XDG_CONFIG_HOME/git/config

~/.gitconfig
local: $GIT_DIR/config
робоче дерево: $GIT_DIR/config.worktree
command: Змінні середовища GIT_CONFIG_{COUNT,KEY,VALUE} (див. НАВКОЛИШНЄ СЕРЕДОВИЩЕ нижче)

опція -c

За винятком «command», кожна область видимості відповідає параметру командного рядка: --system, --global, --local, --worktree.

Під час читання параметрів, якщо вказати область видимості, параметри будуть зчитуватися лише з файлів у межах цієї області видимості. Під час запису параметрів, якщо вказати область видимості, параметри будуть записуватися у файли в межах цієї області видимості (замість файлу конфігурації репозиторію). Повний опис див. у ОПЦІЇ вище.

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

Захищена конфігурація

Захищена конфігурація стосується областей видимості «система», «глобальна» та «команда». З міркувань безпеки певні параметри враховуються лише тоді, коли вони вказані в захищеній конфігурації, та ігноруються в іншому випадку.

Git обробляє ці області видимості так, ніби вони контролюються користувачем або довіреним адміністратором. Це пояснюється тим, що зловмисник, який контролює ці області видимості, може завдати значної шкоди без використання Git, тому передбачається, що середовище користувача захищає ці області видимості від зловмисників.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Візьміть конфігурацію з наданих файлів, а не з глобальної або системної конфігурації. Див. git[1] для отримання детальної інформації.
GIT_CONFIG_NOSYSTEM: Чи слід пропускати зчитування налаштувань із системного файлу $(prefix)/etc/gitconfig. Див. git[1] для отримання детальної інформації.

Див. також ФАЙЛИ.

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>: Якщо для GIT_CONFIG_COUNT встановлено додатне число, усі пари середовища GIT_CONFIG_KEY_<n> та GIT_CONFIG_VALUE_<n> до цього числа будуть додані до конфігурації середовища виконання процесу. Пари конфігурацій мають нульовий індекс. Будь-який відсутній ключ або значення обробляється як помилка. Порожній GIT_CONFIG_COUNT обробляється так само, як GIT_CONFIG_COUNT=0, тобто жодні пари не обробляються. Ці змінні середовища перевизначають значення у файлах конфігурації, але будуть перевизначені будь-якими явними опціями, переданими через git -c.

Це корисно у випадках, коли ви хочете створити кілька команд git зі спільною конфігурацією, але не можете покладатися на файл конфігурації, наприклад, під час написання скриптів.
GIT_CONFIG: Якщо для git config не надано опцію --file, використовуйте файл, наданий GIT_CONFIG, так, ніби він надано через --file. Ця змінна не впливає на інші команди Git і здебільшого призначена для історичної сумісності; зазвичай немає причин використовувати її замість опції --file.

ПРИКЛАДИ

Враховуючи .git/config like this:

#
# Це конфігураційний файл, і
# символ '#' або ';' вказує
# на коментар
#

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

; Наш алгоритм диференціації
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

; Налаштування проксі-сервера
[core]
	gitproxy=proxy-command for kernel.org
	gitproxy=default-proxy ; for all the rest

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
	cookieFile = /tmp/cookie.txt

Ви можете встановити файловий режим на true за допомогою

% git config set core.filemode true

Гіпотетичні записи команд проксі насправді мають постфікс, щоб розрізняти, до якої URL-адреси вони застосовуються. Ось як змінити запис для kernel.org на "ssh".

% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'

Це гарантує, що замінюється лише пара ключ/значення для kernel.org.

Щоб видалити запис для перейменування, виконайте такі дії

% git config unset diff.renames

Якщо ви хочете видалити запис для багатозмінної (як core.gitproxy вище), вам потрібно надати регулярний вираз, що відповідає значенню рівно одного рядка.

Щоб запитати значення для заданого ключа, виконайте такі дії

% git config get core.filemode

або, щоб запитати багатовимірну змінну:

% git config get --value="for kernel.org$" core.gitproxy

Якщо ви хочете знати всі значення для багатоваріантної величини, виконайте такі дії:

% git config get --all --show-names core.gitproxy

Якщо ви любите жити небезпечно, ви можете замінити весь core.gitproxy на новий з

% git config set --all core.gitproxy ssh

Однак, якщо ви дійсно хочете замінити лише рядок для проксі-сервера за замовчуванням, тобто той, що без постфікса "for …", зробіть щось подібне:

% git config set --value='! for ' core.gitproxy ssh

Щоб фактично знайти лише значення зі знаком оклику, потрібно

% git config set --value='[!]' section.key value

Щоб додати новий проксі-сервер, не змінюючи жодного з існуючих, використовуйте

% git config set --append core.gitproxy '"proxy-command" для example.com'

Приклад використання налаштованого кольору з конфігурації у вашому скрипті:

#!/bin/sh
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
RESET=$(git config get --type=color --default="reset" "")
echo "${WS}your whitespace color or blue reverse${RESET}"

Для URL-адрес у https://weak.example.com, http.sslVerify має значення false, тоді як для всіх інших URL-адрес має значення true:

% git config get --type=bool --url=https://good.example.com http.sslverify
true
% git config get --type=bool --url=https://weak.example.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt
http.sslverify false

ФАЙЛ КОНФІГУРАЦІЇ

Файл конфігурації Git містить низку змінних, які впливають на поведінку команд Git. Файли .git/config та, за бажанням, config.worktree (див. розділ "ФАЙЛ КОНФІГУРАЦІЇ" у git-worktree[1]) у кожному репозиторії використовуються для зберігання конфігурації цього репозиторію, а $HOME/.gitconfig використовується для зберігання конфігурації для кожного користувача як резервних значень для файлу .git/config. Файл /etc/gitconfig можна використовувати для зберігання загальносистемної конфігурації за замовчуванням.

Змінні конфігурації використовуються як командами Git plumbing, так і командами porcelain. Змінні поділені на секції, де повна назва змінної – це останній сегмент, розділений крапками, а назва секції – це все, що знаходиться перед останньою крапкою. Назви змінних не враховують регістр, дозволяють використовувати лише буквено-цифрові символи та -, і повинні починатися з літери. Деякі змінні можуть зустрічатися кілька разів; тоді ми кажемо, що змінна є багатозначною.

Синтаксис

Синтаксис досить гнучкий та дозвільний. Пробільні символи, якими в цьому контексті є пробіл (SP) та горизонтальна табуляція (HT), здебільшого ігноруються. Символи # та ; розпочинають коментарі до кінця рядка. Порожні рядки ігноруються.

Файл складається з розділів та змінних. Розділ починається з назви розділу в квадратних дужках і триває до початку наступного розділу. Назви розділів не враховують регістр. В іменах розділів дозволені лише буквено-цифрові символи, - та .. Кожна змінна повинна належати до певного розділу, що означає, що перед першим налаштуванням змінної має бути заголовок розділу.

Розділи можна додатково розділити на підрозділи. Щоб розпочати підрозділ, візьміть його назву в подвійні лапки, відокремивши її пробілом від назви розділу, у заголовку розділу, як у прикладі нижче:

	[section "subsection"]

Назви підрозділів чутливі до регістру та можуть містити будь-які символи, окрім символу нового рядка та нульового байта. Подвійні лапки " та зворотну скісну риску можна включати, екрануючи їх як \" та \\ відповідно. Зворотні скісну риску перед іншими символами пропускаються під час читання; наприклад, \t читається як t, а \0 читається як 0. Заголовки розділів не можуть охоплювати кілька рядків. Змінні можуть належати безпосередньо до розділу або до заданого підрозділу. Ви можете мати [розділ], якщо у вас є [розділ "підрозділ"], але це не обов’язково.

Також існує застарілий синтаксис [section.subsection]. У цьому синтаксисі назва підрозділу перетворюється на малу літеру та порівнюється з урахуванням регістру. Ці назви підрозділів дотримуються тих самих обмежень, що й назви розділів.

Усі інші рядки (і решта рядка після заголовка розділу) розпізнаються як змінні-налаштування у формі «назва = значення» (або просто «назва», що є скороченням від логічного значення «true»). Назви змінних не враховують регістр, дозволяють використовувати лише буквено-цифрові символи та -, і повинні починатися з літери.

Пробільні символи навколо name, = та value відкидаються. Внутрішні пробільні символи всередині value зберігаються дослівно. Коментарі, що починаються з # або ; і продовжуються до кінця рядка, відкидаються. Рядок, який визначає значення, можна продовжити до наступного рядка, завершивши його зворотною скісну рискою (\); зворотна скісну риску та символи кінця рядка відкидаються.

Якщо value має містити початкові або кінцеві пробіли, його потрібно взяти в подвійні лапки ("). Усередині подвійних лапок символи подвійних лапок (") та зворотної скісної риски (\) повинні бути екрановані: використовуйте \" замість " та \\ замість \.

Розпізнаються такі escape-послідовності (окрім \" та \\): \n для символу нового рядка (NL), \t для горизонтальної табуляції (HT, TAB) та \b для символу повернення до коду (BS). Інші escape-послідовності символів (включаючи вісімкові escape-послідовності) є недійсними.

Включає

Розділи include та includeIf дозволяють вам включати директиви конфігурації з іншого джерела. Ці розділи поводяться ідентично один одному, за винятком того, що розділи includeIf можуть ігноруватися, якщо їхня умова не є true; див. "Умовні включення" нижче.

Ви можете включити конфігураційний файл з іншого файлу, встановивши спеціальну змінну include.path (або includeIf.*.path) на ім’я файлу, який потрібно включити. Змінна приймає шлях як значення та підлягає розширенню тильдою. Ці змінні можна вводити кілька разів.

Вміст підключаного файлу вставляється негайно, ніби він був знайдений у місці розташування директиви include. Якщо значення змінної є відносним шляхом, шлях вважається відносним до файлу конфігурації, в якому було знайдено директиву include. Див. приклади нижче.

Умовне включення

Ви можете умовно включити конфігураційний файл з іншого, встановивши змінну includeIf.<condition>.path на ім’я файлу, який потрібно включити.

Умова починається з ключового слова, за яким йде двокрапка та деякі дані, формат та значення яких залежать від ключового слова. Підтримувані ключові слова:

gitdir

Дані, що йдуть після ключового слова gitdir:, використовуються як шаблон glob. Якщо розташування каталогу .git відповідає шаблону, умова включення виконується.

Розташування .git може бути автоматично виявлене або походити зі змінної середовища $GIT_DIR. Якщо репозиторій автоматично виявлено через файл .git (наприклад, з підмодулів або пов’язаного робочого дерева), розташування .git буде кінцевим розташуванням, де знаходиться каталог .git, а не місцем, де знаходиться файл .git.

Шаблон може містити стандартні шаблони підстановки та два додаткові, **/ та /**, які можуть відповідати кільком компонентам шляху. Для отримання детальної інформації зверніться до gitignore[5]. Для зручності:

Якщо шаблон починається з ~/, ~ буде замінено вмістом змінної середовища HOME.
Якщо шаблон починається з ./, він замінюється назвою каталогу, що містить поточний файл конфігурації.
Якщо шаблон не починається з ~/, ./ або /, автоматично буде додано **/. Наприклад, шаблон foo/bar стає **/foo/bar і відповідатиме /any/path/to/foo/bar.
Якщо шаблон закінчується на /, автоматично буде додано **. Наприклад, шаблон foo/ стає foo/**. Іншими словами, він рекурсивно збігається з "foo" та всім, що всередині нього.

gitdir/i

Це те саме, що й gitdir, за винятком того, що зіставлення виконується без урахування регістру (наприклад, на файлових системах без урахування регістру)

onbranch

Дані, що йдуть після ключового слова onbranch:, вважаються шаблоном зі стандартними шаблонами глобального підстановлення та двома додатковими, **/ та /**, які можуть відповідати кільком компонентам шляху. Якщо ми знаходимося в робочому дереві, де назва гілки, яка наразі витягується, відповідає шаблону, умова включення виконується.

Якщо шаблон закінчується на /, автоматично буде додано **. Наприклад, шаблон foo/ стає foo/**. Іншими словами, він відповідає всім гілкам, які починаються з foo/. Це корисно, якщо ваші гілки організовані ієрархічно, і ви хочете застосувати конфігурацію до всіх гілок у цій ієрархії.

hasconfig:remote.*.url:

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

Файли, що включаються цією опцією (прямо чи опосередковано), не можуть містити віддалені URL-адреси.

Зверніть увагу, що на відміну від інших умов includeIf, вирішення цієї умови залежить від інформації, яка ще не відома на момент зчитування умови. Типовим варіантом використання є присутність цього параметра як конфігурації системного або глобального рівня, а віддалена URL-адреса знаходиться в конфігурації локального рівня; звідси виникає необхідність попереднього сканування під час вирішення цієї умови. Щоб уникнути проблеми курки та яйця, коли потенційно включені файли можуть впливати на те, чи будуть такі файли потенційно включені, Git розриває це коло, забороняючи цим файлам впливати на вирішення цих умов (таким чином, забороняючи їм оголошувати віддалені URL-адреси).

Що стосується найменування цього ключового слова, то воно призначене для прямої сумісності зі схемою іменування, яка підтримує більше умов включення на основі змінних, але наразі Git підтримує лише точне ключове слово, описане вище.

Ще кілька зауважень щодо зіставлення через gitdir та gitdir/i:

Символічні посилання в $GIT_DIR не вирішуються перед зіставленням.
Як символічне посилання, так і реальний шлях будуть збігатися поза $GIT_DIR. Наприклад, якщо ~/git є символічним посиланням на /mnt/storage/git, то збігатимуться як gitdir:~/git, так і gitdir:/mnt/storage/git.

У початковому випуску цієї функції версії 2.13.0, який відповідав лише версії realpath, такого не було. Конфігурація, сумісна з початковим випуском цієї функції, повинна вказувати або лише версію realpath, або обидві версії.
Зверніть увагу, що "../" не є спеціальним символом і відповідатиме буквально, що навряд чи вам потрібно.

Приклад

# Основні змінні
[core]
	; Не довіряйте режимам файлів
	filemode = false

# Наш алгоритм диференціації
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

[branch "devel"]
	remote = origin
	merge = refs/heads/devel

# Налаштування проксі-сервера
[core]
	gitProxy="ssh" for "kernel.org"
	gitProxy=default-proxy ; for the rest

[include]
	path = /path/to/foo.inc ; include by absolute path
	path = foo.inc ; find "foo.inc" relative to the current file
	path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory

; include if $GIT_DIR is /path/to/foo/.git
[includeIf "gitdir:/path/to/foo/.git"]
	path = /path/to/foo.inc

; include for all repositories inside /path/to/group
[includeIf "gitdir:/path/to/group/"]
	path = /path/to/foo.inc

; include for all repositories inside $HOME/to/group
[includeIf "gitdir:~/to/group/"]
	path = /path/to/foo.inc

; relative paths are always relative to the including
; file (if the condition is true); their location is not
; affected by the condition
[includeIf "gitdir:/path/to/group/"]
	path = foo.inc

; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
	path = foo.inc

; include only if a remote with the given URL exists (note
; that such a URL may be provided later in a file or in a
; file read after this file is read, as seen in this example)
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
	path = foo.inc
[remote "origin"]
	url = https://example.com/git

Значенні

Значення багатьох змінних обробляються як простий рядок, але є змінні, які приймають значення певних типів, і існують правила їх написання.

логічний

Коли кажуть, що змінна приймає логічне значення, для «true» та «false» прийнятно багато синонімів; усі вони не враховують регістр.

true: Булеві літерали, що відповідають дійсності, це yes, on, true та 1. Також змінна, визначена без = <value>, сприймається як true.
false: Булеві літерали типу «хибно» – це no, off, false, 0 та порожній рядок.

Під час перетворення значення до його канонічної форми за допомогою специфікатора типу --type=bool, git config гарантуватиме, що вивід буде "true" або "false" (пишеться малими літерами).

integer

Значення багатьох змінних, що визначають різні розміри, можуть мати суфікси k, M тощо, що означають «масштабувати число на 1024», «на 1024x1024» тощо.

color

Значенням змінної, яка приймає колір, є список кольорів (щонайбільше два, один для переднього плану та один для фону) та атрибутів (скільки завгодно), розділених пробілами.

Прийнятні основні кольори: «звичайний», «чорний», «червоний», «зелений», «жовтий», «синій», «пурпуровий», «блакитний», «білий» та «за замовчуванням». Перший заданий колір — це колір переднього плану; другий — колір фону. Усі основні кольори, крім «звичайного» та «за замовчуванням», мають яскравий варіант, який можна вказати, додавши перед кольором префікс «яскравий», наприклад, «яскраво-червоний».

Колір normal не змінює колір. Він такий самий, як порожній рядок, але може використовуватися як колір переднього плану, якщо вказати лише колір фону (наприклад, "normal red").

Колір default явно скидає колір термінала до значення за замовчуванням, наприклад, щоб вказати очищений фон. Хоча це залежить від терміналу, зазвичай це не те саме, що встановити значення "білий/чорний".

Кольори також можуть бути задані числами від 0 до 255; вони використовують 256-кольоровий режим ANSI (але зауважте, що не всі термінали можуть підтримувати це). Якщо ваш термінал підтримує це, ви також можете вказати 24-бітні значення RGB у шістнадцятковому форматі, наприклад #ff0ab3, або 12-бітні значення RGB, наприклад #f1b, що еквівалентно 24-бітному кольору #ff11bb.

Допустимі атрибути: bold, dim, ul, blink, reverse, italic та strike (для перекреслених або «закреслених» літер). Положення будь-яких атрибутів відносно кольорів (до, після або посередині) не має значення. Певні атрибути можна вимкнути, додавши перед ними префікс no або no- (наприклад, noreverse, no-ul тощо).

Псевдоатрибут reset скидає всі кольори та атрибути перед застосуванням заданого кольору. Наприклад, reset green призведе до зеленого переднього плану та фону за замовчуванням без будь-яких активних атрибутів.

Порожній рядок кольору взагалі не створює жодного колірного ефекту. Це можна використовувати, щоб уникнути забарвлення певних елементів, не вимикаючи колір повністю.

Для попередньо визначених кольорових слотів git атрибути мають скидатися на початку кожного елемента у кольоровому виводі. Тож встановлення color.decorate.branch на black зафарбує назву цієї гілки у звичайний чорний, навіть якщо попередній елемент у тому ж рядку виводу (наприклад, відкриваюча дужка перед списком назв гілок у виводі log --decorate) налаштовано на зафарбовування bold або якимось іншим атрибутом. Однак, користувацькі формати журналів можуть мати складніше та шаруватіше забарвлення, і заперечені форми можуть бути там корисними.

pathname

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

Якщо шлях починається з %(prefix)/, решта інтерпретується як шлях відносно "префікса середовища виконання" Git, тобто відносно місця, де було встановлено сам Git. Наприклад, %(prefix)/bin/ посилається на каталог, в якому знаходиться сам виконуваний файл Git. Якщо Git було скомпільовано без підтримки префіксів середовища виконання, замість нього буде підставлено скомпільований префікс. У малоймовірному випадку, якщо потрібно вказати літерал шляху, який не слід розширювати, його потрібно починати з ./, ось так: ./%(prefix)/bin.

Варіантів

Зверніть увагу, що цей список не є вичерпним і не обов’язково повним. Для змінних, що стосуються певних команд, ви знайдете детальніший опис на відповідній сторінці довідки.

Інші інструменти, пов’язані з git, можуть використовувати власні змінні та використовують їх. Вигадуючи нові змінні для використання у власному інструменті, переконайтеся, що їхні назви не конфліктують з тими, що використовуються самим Git та іншими популярними інструментами, і опишіть їх у своїй документації.

Warning

Missing uk/config/add.adoc