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

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

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

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

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

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

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

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

Наказує git add продовжувати додавання файлів, якщо деякі файли неможливо додати через помилки індексації. Еквівалентно опції --ignore-errors у git-add[1]. add.ignore-errors застарів, оскільки він не відповідає звичайним правила іменування для змінних конфігурації.

Вказує командам git branch, git switch та git checkout створювати нові гілки таким чином, щоб команда git-pull[1] могла правильно об’єднати зміни, починаючи з гілки-відправної точки. Зверніть увагу, що навіть якщо цей параметр не вказано, таку поведінку можна вибрати для кожної гілки окремо за допомогою параметрів --track та --no-track. Стандартним значенням цього параметра є true. Допустимі значення:

Коли за допомогою команд git branch, git switch або git checkout створюється нова гілка, яка відстежує іншу гілку, ця змінна вказує Git налаштувати операцію pull на rebase замість merge (див. branch.<name>.rebase). Допустимі значення:

Ця змінна визначає порядок сортування гілок під час їх перегляду за допомогою команди git-branch[1]. Якщо не вказано опцію --sort=<value>, як стандартне значення буде використано значення цієї змінної. Див. git-for-each-ref[1] «Назви полів» для ознайомлення з допустимими значеннями.

Коли ви перебуваєте в гілці <name>, це вказує командам git fetch та git push, з якого віддаленого сервера слід завантажувати дані або на який їх надсилати. Віддалений сервер для надсилання даних можна перевизначити за допомогою параметра remote.pushDefault (для всіх гілок). Віддалений сервер для надсилання даних для поточної гілки можна додатково перевизначити за допомогою параметра branch. <name>.pushRemote. Якщо віддалений сервер не налаштований, або якщо ви не перебуваєте в жодній гілці, а в репозиторії визначено більше одного віддаленого сервера, зазвичай для завантаження використовується origin, а для надсилання — remote.pushDefault. Крім того, . (крапка) — це поточний локальний репозиторій (репозиторій з крапкою), див. останню примітку щодо branch.<name>.merge нижче.

Перебуваючи у гілці <name>, ця опція замінює значення branch.<name>.remote під час надсилання. Вона також замінює remote.pushDefault для надсилання з гілки <name>. Коли ви завантажуєте з одного місця (наприклад, вашого upstream) і надсилаєте в інше місце (наприклад, у власний репозиторій для публікації), вам слід встановити remote.pushDefault, щоб вказати віддалений сервер для надсилання для всіх гілок, і використовувати цю опцію, щоб замінити це значення для конкретної гілки.

Разом із branch.<name>.remote визначає гілку-джерело для вказаної гілки. Вказує командам git fetch/git pull/git rebase, яку гілку слід об’єднати, а також може впливати на команду git push (див. push.default). Перебуваючи в гілці <name>, вказує команді git fetch стандартне значення refspec, яке слід позначити для об’єднання в FETCH_HEAD. Значення обробляється як віддалена частина refspec і має відповідати ref, який завантажується з віддаленого репозиторію, вказаного branch.<name>.remote. Інформація про злиття використовується git pull (який спочатку викликає git fetch) для пошуку стандартної гілки для злиття. Без цієї опції git pull стандартно зливає перший завантажений refspec. Вкажіть кілька значень, щоб отримати злиття «octopus». Якщо ви хочете налаштувати git pull так, щоб він зливав у <name> з іншої гілки в локальному репозиторії, ви можете вказати branch.<name>.merge на бажану гілку та використовувати відносний шлях . (крапка) для branch.<name>.remote.

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

Якщо встановлено, під час виконання команди git pull гілку <name> буде перебазовано на вершину завантаженої гілки замість стандартно злиття з гілкою зі стандартного віддаленого репозиторію. Щоб виконати цю дію незалежно від конкретної гілки, див. параметр 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. Його можна перевизначити, передавши --origin у командному рядку у git-clone[1].

Відхиляє клонування репозиторію, якщо він поверхневий; це можна змінити, передавши опцію --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, доцільно скористатися агентом.

Булеве значення, яке визначає, чи включати інформацію про стан у шаблон повідомлення про коміт під час підготовки повідомлення за допомогою редактора. Стандартне значення — true.

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

Булеве значення або ціле число для визначення рівня деталізації команди git commit. See git-commit[1] for details.

Під час використання git diff для порівняння з файлами робочого дерева зміни, що стосуються лише статистичних даних, не розглядаються як зміни. Натомість без попередження виконується команда git update-index --refresh, щоб оновити кешовану інформацію про статистику для шляхів, вміст яких у робочому дереві збігається з вмістом індексу. Типовим значенням цієї опції є true. Зверніть увагу, що це впливає лише на git diff Porcelain, а не на команди diff нижчого рівня, такі як git diff-files.

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

Обмежує ширину частини імені файлу у виводі --stat. Якщо встановлено, застосовується до всіх команд, що генерують вивід --stat, окрім format-patch.

Обмежує ширину частини графу у виводі --stat. Якщо встановлено, застосовується до всіх команд, що генерують вивід --stat, окрім format-patch.

Генерує відмінності з <n> рядками контексту замість стандартних 3-х. Це значення перевизначається опцією -U.

Показує контекст між відмінностями фрагментів (diff hanks) до вказаної кількості рядків, обʼєднуючи таким чином ті ханфрагментии, що знаходяться поруч. Це значення є стандартним для параметра командного рядка --inter-hunk-context.

Якщо ця змінна конфігурації встановлена, порівняння виконується не за допомогою внутрішнього механізму, а за допомогою вказаної команди. Цю налаштування можна замінити за допомогою змінної середовища GIT_EXTERNAL_DIFF. Команда викликається з параметрами, описаними в розділі «git Diffs» у документації git[1]. Примітка: якщо ви хочете використовувати зовнішню програму порівняння лише для частини ваших файлів, вам може знадобитися gitattributes[5].

Якщо для цього булевого значення встановлено значення true, то команда diff.external повинна повертати код завершення 0, якщо вона вважає вхідні файли однаковими, або 1, якщо вважає їх різними, як і команда diff(1). Якщо встановлено значення false (що є стандартним значенням), то команда повинна повертати код завершення 0 незалежно від того, чи файли однакові. Будь-який інший код завершення змушує Git повідомити про фатальну помилку.

Встановлює стандартне значення параметра --ignore-submodules. Зверніть увагу, що це впливає лише на Porcelain`git diff`, а не на команди diff нижчого рівня, такі як git diff-files. Команди git checkout та git switch також враховують це налаштування під час показу змін, що не зафіксовані. Встановлення значення all вимикає вивід підсумкової інформації субмодулів, яка зазвичай показується командами git commit та git status, коли встановлено status.submoduleSummary, якщо це не замінено за допомогою опції командного рядка --ignore-submodules. На команди git submodule це налаштування не впливає. Стандартно встановлено значення untracked, щоб ігнорувати будь-які не відстежувані субмодулі.

Якщо встановлено, git diff використовує пару префіксів, яка відрізняється від стандартних a/ та b/, залежно від того, що порівнюється. Коли ця конфігурація діє, зворотний вивід diff також змінює порядок префіксів:

Якщо встановлено, git diff не показує жодного префікса джерела чи призначення.

Якщо встановлено, git diff використовуватиме цей префікс джерела. Стандартно a/.

Якщо встановлено, git diff використовуватиме цей префікс призначення. Стандартно b/.

Якщо встановлено значення true, git diff не показує зміни поза текою та показує шляхи відносно поточної теки.

Файл, що вказує, як упорядкувати файли в межах diff. Дивіться опис параметра -O для git-diff[1] для отримання детальної інформації. Якщо diff.orderFile є відносним шляхом, він розглядається як відносний до вершини робочого дерева.

Кількість файлів, які слід врахувати під час вичерпного аналізу на наявність дублікатів або перейменувань; відповідає опції -l команди git diff. Якщо значення не вказано, використовується стандартне значення — 1000. Цей параметр не діє, якщо виявлення перейменувань вимкнено.

Чи виявляє Git перейменування та яким чином. Якщо встановлено значення false, виявлення перейменувань вимкнено. Якщо встановлено значення true, увімкнено базове виявлення перейменувань. Якщо встановлено значення copies або copy, Git також виявлятиме копії. Стандартне значення — true. Зверніть увагу, що це впливає лише на git diff Porcelain, такі як git-diff[1] та git-log[1], а не на команди нижчого рівня, такі як git-diff-files[1].

Булеве значення, яке пригнічує стандартну поведінку, що передбачає вставку пробілу перед кожним порожнім рядком виводу. Стандартне значення — false.

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

Розширений регулярний вираз POSIX, що використовується для визначення поняття «слово» під час обчислення відмінностей пословно. Послідовності символів, що відповідають цьому регулярному виразу, є «словами», а всі інші символи — це ігноровані пробіли.

Команда власного драйвера diff. Див. gitattributes[5] для отримання детальної інформації.

Якщо для цього булевого значення встановлено значення true, то команда diff.<driver>.command повинна повертати код завершення 0, якщо вона вважає вхідні файли однаковими, або 1, якщо вважає їх різними, як і diff(1). Якщо встановлено значення false (що є стандартним значенням), то команда повинна повертати код завершення 0 незалежно від того, чи файли однакові. Будь-який інший код завершення змушує Git повідомити про фатальну помилку.

Регулярний вираз, який драйвер diff повинен використовувати для розпізнавання заголовка фрагмента. Також може використовуватися вбудований шаблон. Див. gitattributes[5] для отримання детальної інформації.

Встановлення для цього параметра значення true змушує драйвер diff обробляти файли як бінарні. Детальніше див. gitattributes[5].

Команда, яку драйвер diff має викликати для створення текстової версії файлу. Результат перетворення використовується для створення зручного для читання diff. Див. gitattributes[5] для отримання детальної інформації.

Регулярний вираз, який драйвер diff має використовувати для розділення слів у рядку. Див. gitattributes[5] для отримання детальної інформації.

Встановлення цього параметра в значення true змусить драйвер diff кешувати результати перетворення тексту. Детальніше див. gitattributes[5].

Встановлення цього параметра в значення false дозволить вимкнути стандартну евристику, яка зміщує межі фрагментів diff для полегшення читання латок.

Вибір алгоритму порівняння. Є наступні варіанти:

Підсвічувати помилки у пробілах у рядках context, old або new у diff. Кілька значень розділяються комою, none скидає попередні значення, default скидає список до new, а all є скороченим варіантом old,new,context. Помилки пробілів підсвічуються кольором color.diff.whitespace. Параметр командного рядка --ws-error-highlight=<kind> замінює це налаштування.

Якщо встановлено дійсне значення <mode> або true, переміщені рядки в diff матимуть інший колір. Детальніше про допустимі режими див. у розділі --color-moved у git-diff[1]. Якщо просто встановити значення true, буде використано стандартний колірний режим. Коли встановлено значення false, переміщені лінії не забарвлюються.

Коли переміщені рядки забарвлюються, наприклад, за допомогою параметра diff.colorMoved, цей параметр контролює режим обробки пробілів. Докладніше про допустимі режими див. у --color-moved-ws у git-diff[1].

Ця опція визначає, чи буде команда git fetch (а також відповідний виклик fetch у команді git pull) рекурсивно завантажувати дані в субмодулі. Цю опцію можна встановити як булеве значення або як on-demand. Встановлення булевого значення змінює поведінку команд fetch і pull: при значенні true вони беззастережно виконують рекурсію в субмодулях, а при значенні false — не виконують її взагалі. При значенні on-demand, команди fetch та pull будуть рекурсивно завантажувати дані в заповнений субмодуль тільки тоді, коли його суперпроєкт отримує коміт, що оновлює посилання субмодуля. Стандартним значенням є 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, не перевищує цього обмеження, об’єкти будуть розпаковані у вигляді окремих файлів. Однак якщо кількість отриманих об’єктів дорівнює цьому обмеженню або перевищує його, отриманий пакунок буде збережено як пакунок після додавання будь-яких відсутніх базових файлів дельта. Збереження пакунка з операції push може прискорити завершення цієї операції, особливо на повільних файлових системах. Якщо це значення не вказано, замість нього використовується значення transfer.unpackLimit.

Якщо значення —true, fetch буде поводитись так ніби опцію --prune було вказано в командному рядку. Див. також remote.<name>.prune та розділ ОЧИЩЕННЯ в git-fetch[1].

Якщо значення — true, то під час очищення fetch автоматично поводитиметься так, ніби під час очищення було вказано refspec refs/tags/*:refs/tags/*, якщо він ще не встановлений. Це дозволяє встановити як цей параметр, так і fetch.prune, щоб зберегти співвідношення 1:1 з refs upstream. Див. також remote.<name>.pruneTags та розділ ОЧИЩЕННЯ в git-fetch[1].

Якщо значення — true, fetch намагатиметеся оновлювати всі доступні remotes. Цю поведінку можна перевизначити використанням параметра --no-all або явним вказанням одного чи більше remote для fetch. Стандартно – false.

Керує тим, як показується статус оновлення ref. Допустимі значення: full та compact. Стандартне значення — full. Детальніше див. розділ ВИВІД у документації git-fetch[1].

Керує тим, як надсилається інформація про коміти в локальному репозиторії під час узгодження вмісту файлу packfile, який має надіслати сервер. Встановіть значення consecutive, щоб використовувати алгоритм, який послідовно перевіряє кожен з послідовних комітів. Встановіть значення skipping, щоб використовувати алгоритм, який пропускає коміти з метою швидшого збігу, але це може призвести до створення файлу packfile, розмір якого перевищує необхідний; або встановіть значення noop, щоб не надсилати жодної інформації, що майже напевно призведе до створення файлу packfile, розмір якого перевищує необхідний, але дозволить пропустити етап узгодження. Встановіть значення 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 із URI набору перед виконанням інкрементального завантаження з оригінального сервера Git. Це схоже на те, як працює опція --bundle-uri у команді git-clone[1]. Команда git clone --bundle-uri встановить значення fetch.bundleURI, якщо вказаний 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].

Виводити назви ref усіх комітів, які показує команда log. Можливі значення:

Зазвичай git log показує лише оформлення для певних відомих просторів імен ref. Якщо вказано «all», то всі refs показуються з оформленням.

Виключити вказані шаблони з оформлення журналу. Це аналогічно параметру командного рядка --decorate-refs-exclude, але значення цього параметра конфігурації може бути замінено параметром --decorate-refs.

Встановлює формат diff, який буде використовуватися при вказанні параметра --diff-merges=on. Детальніше див. --diff-merges у git-log[1]. Стандартним значенням є separate.

Якщо встановлено значення true, команда git log буде працювати так, ніби було вказано опцію --follow, коли задано один <path>. Ця опція має ті самі обмеження, що й --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 викликається без аргументу commit, виконується злиття гілок upstream, налаштованих для поточної гілки, з використанням їхніх останніх значень, збережених у гілках remote-tracking. Перевіряються значення branch.<current branch>.merge, які називають гілки на віддаленому сервері, названому branch.<current-branch>.remote, а потім вони зіставляються за допомогою remote.<remote>.fetch з відповідними гілками віддаленого відстеження, і вершини цих гілок відстеження зливаються. Стандартне значення — true.

Стандартно Git не створює додаткового коміту злиття під час злиття коміту, який є нащадком поточного коміту. Натомість вершина поточної гілки переноситься вперед (fast-forward). Якщо для цієї змінної встановлено значення false, Git створює додатковий коміт злиття в такому випадку (що еквівалентно введенню опції --no-ff у командному рядку). Якщо встановлено значення only, дозволяються лише такі злиття з переміщенням вперед (що еквівалентно введенню опції --ff-only у командному рядку).

Якщо це значення true, це еквівалентно опції командного рядка --verify-signatures. Див. git-merge[1] для отримання детальної інформації.

Окрім назв гілок, заповнювати повідомлення журналу текстом опису гілок, повʼязаним із ними. Стандартне значення — false.

Окрім назв гілок, заповнювати повідомлення журналу щонайбільше вказаною кількістю однорядкових описів з фактичних комітів, що обʼєднуються. Станадртне значення — false, а true є синонімом 20.

Якщо додати до цієї багатозначної конфігураційної змінної шаблон, що відповідає назвам гілок інтеграції, у титулі стандартного повідомлення про злиття, яке генерується під час злиття в ці гілки інтеграції, буде опущено фрагмент «into <branch-name>».

Кількість файлів, які слід враховувати під час вичерпної перевірки на перейменування під час злиття. Якщо значення не вказано, зазвичай використовується значення 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.<tool>.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 і є стандартним значенням.

Налаштовує макет розділеного вікна для <variant> vimdiff, яким може бути будь-який із варіантів: vimdiff, nvimdiff, gvimdiff. При запуску git mergetool з параметром --tool=<variant> (або без --tool, якщо merge.tool налаштовано як <variant>), Git звернеться до файлу mergetool. <variant>.layout, щоб визначити макет інструменту. Якщо конфігурація для конкретного варіанту недоступна, як запасний варіант використовується конфігурація vimdiff. Якщо вона також недоступна, буде використано макет за замовчуванням із 4 вікнами. Щоб налаштувати макет, див. розділ «ПОРАДИ, ЩО СТОСУЮТЬСЯ БЕКЕНДУ» розділ в git-mergetool[1].

Під час злиття Git автоматично розвʼяже якомога більше конфліктів і створить файл $MERGED, що містить маркери конфліктів навколо тих конфліктів, які він не може вирішити; $LOCAL та $REMOTE зазвичай містять версії файлу, що існували до розвʼязання конфліктів Git. Цей прапорець призводить до перезапису $LOCAL та $REMOTE, щоб інструменту злиття були представлені лише нерозвʼязані конфлікти. Може бути налаштований для кожного інструменту окремо за допомогою змінної конфігурації mergetool.<tool>.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, де для використання merge.guitool необхідно явно вказати аргумент --gui.

Яку стратегію обʼєднання вибрати у якості стандартної під час розвʼязання конфліктів у нотатках. Може бути одним зі значень: manual, ours, theirs, union або cat_sort_uniq. Стандартним значенням є manual. Докладнішу інформацію про кожну стратегію див. у розділі «СТРАТЕГІЇ ОБ’ЄДНАННЯ НОТАТОК» документації git-notes[1].

Яку стратегію злиття обрати під час злиття нотаток у refs/notes/<name>. Цей параметр замінює більш загальний параметр notes.mergeStrategy. Докладнішу інформацію про доступні стратегії див. у розділі «СТРАТЕГІЇ ЗЛИТТЯ НОТАТОК» в git-notes[1].

Який ref (або refs, якщо вказано загальний параметр або кілька разів), крім стандартного, заданого за допомогою core.notesRef або GIT_NOTES_REF, слід використовувати для зчитування приміток під час показу повідомлень про коміти за допомогою команд із сімейства git log.

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

Під час копіювання приміток під час перезапису (див. опцію notes.rewrite.<command>) визначає, що робити, якщо цільовий коміт уже містить примітку. Може приймати значення overwrite, concatenate, cat_sort_uniq або ignore. Стандартним значенням є concatenate.

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

Якщо встановлено значення true, під час стандартного надсилання (push) передбачається використання параметра --set-upstream, якщо для поточної гілки відсутнє відстеження upstream; ця опція діє разом із значеннями параметра push.default: simple, upstream та current. Це корисно, якщо ви хочете, щоб нові гілки стандартно надсилалися до стандартного віддаленого репозиторію (як у випадку з push.default=current) і водночас бажаєте встановити відстеження upstream. Робочі процеси, які, найімовірніше, отримають користь від цієї опції, — це централізовані робочі процеси simple, де очікується, що всі гілки матимуть однакову назву на віддаленому сервері.

Визначає, яку дію має виконати команда git push, якщо не вказано refspec (ні в командному рядку, ні в конфігурації, ні деінде). Різні значення підходять для конкретних робочих процесів; наприклад, у суто централізованому робочому процесі (тобто джерело fetch збігається з пунктом призначення push) вам, ймовірно, підійде значення upstream. Можливі значення:

Якщо встановлено — true, стандартно увімкнути опцію --follow-tags. Ви можете перевизначити це налаштування будь-коли за допомогою --no-follow-tags.

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

Коли в командному рядку немає аргументу --push-option=<option>, git push поводиться так ніби кожне значення <option> цієї змінної було вказано через --push-option=<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.

Стандартний бекенд, що використовується для перебазування. Можливі значення: apply або merge. В майбутньому, якщо бекенд merge набуде всіх можливостей бекенда 'apply, цей параметр перестане використовуватись.

Чи виводити diffstat для того що було змінено в upstream з моменту останнього перебазування. Стандартне значення — false.

Якщо значення — true, параметр --autosquash є стандартно увімкненим для git-rebase[1] в інтерактивному режимі. Він може бути перевизначений за допомоги --no-autosquash.

Якщо значення — true, автоматично створюється тимчасовий елемент stash перед початком операції та застосовується після її завершення. Це означає, що ви можете запустити перебазування на робочому дереві, що містить незафіксовані зміни. Однак використовуйте з обережністю: остаточне застосування 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 The oneline of the commit
	p fa1afe1 The oneline of the next commit
	...

	pick deadbee The oneline of the commit
	pick fa1afe1 The oneline of the next commit
	...

Автоматично перепланувати команди 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 для відповідних вільних посилань).

Текстовий редактор, який використовується командою git rebase -i для редагування файлу інструкцій перебазування. Це значення призначене для інтерпретації оболонкою під час використання. Його можна замінити за допомогою змінної середовища GIT_SEQUENCE_EDITOR. Якщо це значення не вказано, замість нього використовується стандартний редактор повідомлень комітів.

Якщо для цього параметра встановлено значення true, команди git stash apply та git stash pop працюватимуть так, ніби було вказано параметр --index. Стандартне значення — false. Дивись опис в git-stash[1].

Якщо для цього параметра встановлено значення true, команда git stash show покаже файли, що не відстежуються, в елементі сховища. Стандартне значення — false. See the description of the 'show' command in git-stash[1].

Якщо для цього параметра встановлено значення true, команда git stash show без додаткових опцій відображатиме запис про тимчасове збереження у вигляді латки. Стандартне значення — false. See the description of the 'show' command in git-stash[1].

Якщо для цього параметра встановлено значення true, команда git stash show без додаткових опцій відображатиме diffstat запису в сховку. Стандартне значення — true. See the description of the 'show' command in git-stash[1].

Булеве значення, що визначає, чи слід підписувати створені теги з анотаціями за допомогою GPG. Якщо в командному рядку вказано параметр --annotate, він має пріоритет над цим параметром.

Ця зміна керує порядком сортування тегів, що виводяться git-tag[1]. Без використання параметра `--sort=<value>`значення цієї змінної будуть використовуватись як стандартне значення.

Булева змінна, що визначає, чи слід підписувати всі теги за допомогою GPG. Використання цієї опції під час запуску в автоматизованому скрипті може призвести до підписання великої кількості тегів. Тому для того, щоб уникнути багаторазового введення пароля GPG, доцільно використовувати агент. Зверніть увагу, що ця опція не впливає на поведінку підписання тегів, увімкнену за допомогою опцій -u <keyid> або --local-user=<keyid>.

Якщо гілка не вказана і не використовуються параметри -b, -B або --detach, то git worktree add стандартно створює нову гілку з HEAD. Якщо worktree.guessRemote встановлено в значення true, worktree add намагається знайти гілку віддаленого відстеження, імʼя якої однозначно збігається з іменем нової гілки. Якщо така гілка існує, вона вибирається і встановлюється як «upstream» для нової гілки. Якщо такого збігу не вдається знайти, виконується створення нової гілки з поточного HEAD.

Повʼязує робочі дерева за допомогою відносних шляхів (якщо встановлено значення «true») або абсолютних шляхів (якщо встановлено значення «false»). Це особливо корисно в ситуаціях, коли репозиторій та робочі дерева можуть переміщуватися між різними місцями або середовищами. Стандартне значення — «false».