Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
-
2.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.2 no changes
-
2.48.1
2025-01-13
-
2.48.0
2025-01-10
- 2.47.3 no changes
-
2.47.2
2024-11-26
-
2.47.1
2024-11-25
-
2.47.0
2024-10-06
- 2.46.4 no changes
-
2.46.3
2024-11-26
-
2.46.2
2024-09-23
-
2.46.1
2024-09-13
-
2.46.0
2024-07-29
- 2.45.4 no changes
-
2.45.3
2024-11-26
- 2.45.1 → 2.45.2 no changes
-
2.45.0
2024-04-29
- 2.44.4 no changes
-
2.44.3
2024-11-26
- 2.44.1 → 2.44.2 no changes
-
2.44.0
2024-02-23
- 2.43.7 no changes
-
2.43.6
2024-11-26
- 2.43.2 → 2.43.5 no changes
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
-
2.42.4
2024-11-26
- 2.42.2 → 2.42.3 no changes
-
2.42.1
2023-11-02
-
2.42.0
2023-08-21
-
2.41.3
2024-11-26
- 2.41.1 → 2.41.2 no changes
-
2.41.0
2023-06-01
-
2.40.4
2024-11-26
- 2.40.1 → 2.40.3 no changes
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 no changes
-
2.39.0
2022-12-12
- 2.38.3 → 2.38.5 no changes
-
2.38.2
2022-12-11
-
2.38.1
2022-10-07
-
2.38.0
2022-10-02
- 2.37.5 → 2.37.7 no changes
-
2.37.4
2022-10-06
- 2.37.3 no changes
-
2.37.2
2022-08-11
- 2.37.1 no changes
-
2.37.0
2022-06-27
- 2.36.4 → 2.36.6 no changes
-
2.36.3
2022-10-06
-
2.36.2
2022-06-23
- 2.36.1 no changes
-
2.36.0
2022-04-18
- 2.35.6 → 2.35.8 no changes
-
2.35.5
2022-10-06
-
2.35.4
2022-06-23
-
2.35.3
2022-04-13
-
2.35.2
2022-03-23
- 2.35.1 no changes
-
2.35.0
2022-01-24
- 2.34.6 → 2.34.8 no changes
-
2.34.5
2022-10-06
-
2.34.4
2022-06-23
-
2.34.3
2022-04-13
-
2.34.2
2022-03-23
- 2.34.1 no changes
-
2.34.0
2021-11-15
- 2.33.6 → 2.33.8 no changes
-
2.33.5
2022-10-06
-
2.33.4
2022-06-23
-
2.33.3
2022-04-13
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.5 → 2.32.7 no changes
-
2.32.4
2022-10-06
-
2.32.3
2022-06-23
-
2.32.2
2022-04-13
-
2.32.1
2022-03-23
-
2.32.0
2021-06-06
- 2.31.6 → 2.31.8 no changes
-
2.31.5
2022-10-06
-
2.31.4
2022-06-23
-
2.31.3
2022-04-13
-
2.31.2
2022-03-23
-
2.31.1
2021-03-26
-
2.31.0
2021-03-15
- 2.30.7 → 2.30.9 no changes
-
2.30.6
2022-10-06
-
2.30.5
2022-06-23
-
2.30.4
2022-04-13
-
2.30.3
2022-03-23
- 2.30.2 no changes
-
2.30.1
2021-02-08
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 no changes
-
2.26.0
2020-03-22
- 2.25.3 → 2.25.5 no changes
-
2.25.2
2020-03-17
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 no changes
-
2.23.0
2019-08-16
- 2.22.2 → 2.22.5 no changes
-
2.22.1
2019-08-11
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.3 → 2.19.6 no changes
-
2.19.2
2018-11-21
- 2.19.1 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
СИНОПСИС
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 See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
ПОМИЛКИ
Під час використання застарілого синтаксису [section.subsection
] зміна значення призведе до додавання багаторядкового ключа замість зміни, якщо підрозділ задано принаймні одним символом верхнього регістру. Наприклад, коли конфігурація виглядає так
[section.subsection] key = value1
а запуск git
config
section.Subsection.key
value2
призведе до
[section.subsection] key = value1 key = value2
GIT
Частина набору git[1]