Дані, що йдуть після ключового слова 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].

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

Якщо вказано 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, команди git stash apply та git stash pop працюватимуть так, ніби було вказано параметр --index. Стандартне значення — false. See the descriptions in 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».