українська мова ▾ Topics ▾ Latest version ▾ git last updated in 2.51.1

НАЗВА

git - дурний трекер контенту

СИНОПСИС

git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
    [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
    [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
    [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
    [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
    <command> [<args>]

ОПИС

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

Дивіться gittutorial[7] для початку, а потім перегляньте giteveryday[7] для корисного мінімального набору команд. Посібник користувача Git містить більш детальний вступ.

Після того, як ви опануєте основні концепції, ви можете повернутися на цю сторінку, щоб дізнатися, які команди пропонує Git. Ви можете дізнатися більше про окремі команди Git за допомогою команди "git help". Сторінка довідки gitcli[7] містить огляд синтаксису команд командного рядка.

Відформатовану копію останньої документації Git з гіперпосиланнями можна переглянути за адресою https://git.github.io/htmldocs/git.html або https://git-scm.com/docs.

ОПЦІЇ

-v
--version

Виводить версію пакету Git, з якого походить програма «git».

Цей параметр внутрішньо перетворюється на git version ... та приймає ті ж параметри, що й команда git-version[1]. Якщо також вказано --help, він має пріоритет над --version.

-h
--help

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

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

-C <path>

Запускати так, ніби git було запущено в <шлях>, а не в поточному робочому каталозі. Коли задано кілька опцій -C, кожна наступна неабсолютна -C <шлях> інтерпретується відносно попередньої -C <шлях>. Якщо <шлях> присутній, але порожній, наприклад, -C "", то поточний робочий каталог залишається незмінним.

Цей параметр впливає на параметри, які очікують шлях до каталогу, такі як --git-dir та --work-tree, оскільки їхні інтерпретації шляхів будуть здійснюватися відносно робочого каталогу, спричиненого параметром -C. Наприклад, наступні виклики еквівалентні:

git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status
-c <name>=<value>

Передайте команді параметр конфігурації. Надане значення замінить значення з файлів конфігурації. Очікується, що <name> буде у тому ж форматі, що й у git config (підрозділи, розділені крапками).

Зверніть увагу, що пропуск символу = у git -c foo.bar ... дозволено, і це встановлює foo.bar у логічне значення true (як і [foo]bar у конфігураційному файлі). Включення символу equals, але з порожнім значенням (наприклад, git -c foo.bar= ...), встановлює foo.bar у порожній рядок, який git config --type=bool перетворить на false.

--config-env=<name>=<envvar>

Як і -c <назва>=<значення>, надайте змінній конфігурації <назва> значення, де <змінна середовища> — це назва змінної середовища, з якої потрібно отримати значення. На відміну від -c, немає скорочення для безпосереднього встановлення значення в порожній рядок, натомість сама змінна середовища має бути встановлена в порожній рядок. Якщо <змінна середовища> не існує в середовищі, це помилка. <змінна середовища> може не містити знак рівності, щоб уникнути двозначності зі <назва>, що містить його.

Це корисно у випадках, коли ви хочете передати тимчасові параметри конфігурації до git, але робите це в операційних системах, де інші процеси можуть читати ваш командний рядок (наприклад, /proc/self/cmdline), але не ваше середовище (наприклад, /proc/self/environ). Така поведінка є типовою в Linux, але може не бути такою у вашій системі.

Зверніть увагу, що це може додати безпеку для таких змінних, як http.extraHeader, де конфіденційна інформація є частиною значення, але не, наприклад, url.<base>.insteadOf, де конфіденційна інформація може бути частиною ключа.

--exec-path[=<path>]

Шлях до місця встановлення ваших основних програм Git. Цим також можна керувати, встановивши змінну середовища GIT_EXEC_PATH. Якщо шлях не вказано, «git» виведе поточні налаштування та завершить роботу.

--html-path

Виведіть шлях, без косої риски в кінці, де встановлено HTML-документацію Git, та завершіть роботу.

--man-path

Виведіть шлях до сторінок довідки (див. man(1)) для цієї версії Git та вийдіть.

--info-path

Виведіть шлях до інстальованих інформаційних файлів, що документують цю версію Git, та завершіть роботу.

-p
--paginate

Передати весь вивід до less (або, якщо встановлено, $PAGER), якщо стандартний вивід є терміналом. Це замінює параметри конфігурації pager.<cmd> (див. розділ "Механізм конфігурації" нижче).

-P
--no-pager

Не перенаправляйте вивід Git у пейджер.

--git-dir=<path>

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

Вказівка розташування каталогу ".git" за допомогою цього параметра (або змінної середовища GIT_DIR) вимикає пошук репозиторію, який намагається знайти каталог з підкаталогом ".git" (саме так виявляється репозиторій та верхній рівень робочого дерева), та повідомляє Git, що ви знаходитесь на верхньому рівні робочого дерева. Якщо ви не знаходитесь у верхньому каталозі робочого дерева, вам слід повідомити Git, де знаходиться верхній рівень робочого дерева, за допомогою параметра --work-tree=<шлях> (або змінної середовища GIT_WORK_TREE)

Якщо ви просто хочете запустити git так, ніби він був запущений у <шлях>, тоді використовуйте git -C <шлях>.

--work-tree=<path>

Встановіть шлях до робочого дерева. Це може бути абсолютний шлях або шлях відносно поточного робочого каталогу. Це також можна контролювати, встановивши змінну середовища GIT_WORK_TREE та змінну конфігурації core.worktree (див. core.worktree у git-config[1] для більш детального обговорення).

--namespace=<path>

Встановіть простір імен Git. Див. gitnamespaces[7] для отримання додаткової інформації. Еквівалентно встановленню змінної середовища GIT_NAMESPACE.

--bare

Розглядати репозиторій як чистий репозиторій. Якщо середовище GIT_DIR не встановлено, воно встановлюється на поточний робочий каталог.

--no-replace-objects

Не використовуйте замінюючі посилання для заміни об’єктів Git. Це еквівалентно експорту змінної середовища GIT_NO_REPLACE_OBJECTS з будь-яким значенням. Див. git-replace[1] для отримання додаткової інформації.

--no-lazy-fetch

Не вибирати відсутні об’єкти з віддаленого сервера-промісника на вимогу. Корисно разом з git cat-file -e <object>, щоб перевірити, чи об’єкт доступний локально. Це еквівалентно встановленню змінної середовища GIT_NO_LAZY_FETCH на 1.

--no-optional-locks

Не виконуйте додаткові операції, що потребують блокування. Це еквівалентно встановленню GIT_OPTIONAL_LOCKS на 0.

--no-advice

Вимкнути друк усіх підказок.

--literal-pathspecs

Ставтеся до pathspecs буквально (тобто без глобалізації, без магії pathspecs). Це еквівалентно встановленню змінної середовища GIT_LITERAL_PATHSPECS на 1.

--glob-pathspecs

Додайте магію "glob" до всіх специфікацій шляхів. Це еквівалентно встановленню змінної середовища GIT_GLOB_PATHSPECS на 1. Вимкнення глобалізації для окремих специфікацій шляхів можна виконати за допомогою магії специфікацій шляхів ":(літерал)"

--noglob-pathspecs

Додайте "літеральну" магію до всіх специфікацій шляхів. Це еквівалентно встановленню змінної середовища GIT_NOGLOB_PATHSPECS на 1. Увімкнення глобалізації для окремих специфікацій шляхів можна зробити за допомогою магії специфікацій шляхів ":(glob)"

--icase-pathspecs

Додайте магію "icase" до всіх pathspec. Це еквівалентно встановленню змінної середовища GIT_ICASE_PATHSPECS на 1.

--list-cmds=<group>[,<group>…​]

Список команд за групами. Це внутрішній/експериментальний параметр, який може бути змінений або видалений у майбутньому. Підтримувані групи: builtins, parseopt (вбудовані команди, що використовують parse-options), main (усі команди в каталозі libexec), others (усі інші команди в $PATH, що мають префікс git-), list-<category> (див. категорії в command-list.txt), nohelpers (виключити допоміжні команди), alias та config (отримати список команд зі змінної конфігурації completion.commands)

--attr-source=<tree-ish>

Зчитувати gitattributes з <tree-ish> замість робочого дерева. Див. gitattributes[5]. Це еквівалентно встановленню змінної середовища GIT_ATTR_SOURCE.

GIT-КОМАНДИ

Ми поділяємо Git на команди високого рівня ("порцелянові") та команди низького рівня ("сантехніка").

Команди високого рівня (порцеляна)

Ми розділяємо команди porcelain на основні команди та деякі допоміжні утиліти користувача.

Основні команди для роботи з порцеляною

Warning

Missing uk/{build_dir}/cmds-mainporcelain.adoc

See original version for this content.

Допоміжні команди

Маніпулятори:

Warning

Missing uk/{build_dir}/cmds-ancillarymanipulators.adoc

See original version for this content.

Слідчі:

Warning

Missing uk/{build_dir}/cmds-ancillaryinterrogators.adoc

See original version for this content.

Взаємодія з іншими

Ці команди призначені для взаємодії із зовнішнім SCM та з іншими людьми через патч через електронну пошту.

Warning

Missing uk/{build_dir}/cmds-foreignscminterface.adoc

See original version for this content.

Скидання, відновлення та повернення

Існує три команди зі схожими назвами: git reset, git restore та git revert.

  • git-revert[1] йдеться про створення нового коміту, який скасовує зміни, внесені іншими комітами.

  • git-restore[1] йдеться про відновлення файлів у робочому дереві з індексу або іншого коміту. Ця команда не оновлює вашу гілку. Команду також можна використовувати для відновлення файлів в індексі з іншого коміту.

  • git-reset[1] йдеться про оновлення вашої гілки, переміщення підказки для додавання або видалення комітів з гілки. Ця операція змінює історію комітів.

    Команда git reset також може бути використана для відновлення індексу, що перетинається з командою git restore.

Низькорівневі команди (сантехніка)

Хоча Git містить власний шар порцеляни, його низькорівневих команд достатньо для підтримки розробки альтернативних порцелянових шарів. Розробники таких порцелянових шарів можуть почати з ознайомлення з git-update-index[1] та git-read-tree[1].

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

У наступному описі низькорівневі команди поділяються на команди, що маніпулюють об’єктами (у репозиторії, індексі та робочому дереві), команди, що опитують та порівнюють об’єкти, та команди, що переміщують об’єкти та посилання між репозиторіями.

Команди маніпуляцій

Warning

Missing uk/{build_dir}/cmds-plumbingmanipulators.adoc

See original version for this content.

Команди допиту

Warning

Missing uk/{build_dir}/cmds-plumbinginterrogators.adoc

See original version for this content.

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

Синхронізація репозиторіїв

Warning

Missing uk/{build_dir}/cmds-synchingrepositories.adoc

See original version for this content.

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

Warning

Missing uk/{build_dir}/cmds-synchelpers.adoc

See original version for this content.

Внутрішні допоміжні команди

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

Warning

Missing uk/{build_dir}/cmds-purehelpers.adoc

See original version for this content.

Путівники

Наведені нижче сторінки документації є посібниками з концепцій Git.

Warning

Missing uk/{build_dir}/cmds-guide.adoc

See original version for this content.

Інтерфейси репозиторію, команд та файлів

У цій документації обговорюються інтерфейси репозиторію та команд, з якими користувачі повинні безпосередньо взаємодіяти. Див. --user-formats у git-help[1] для отримання додаткової інформації про критерії.

Warning

Missing uk/{build_dir}/cmds-userinterfaces.adoc

See original version for this content.

Формати файлів, протоколи та інші інтерфейси розробника

У цій документації обговорюються формати файлів, протоколи OTP та інші інтерфейси розробника git. Див. --developer-interfaces у git-help[1].

Warning

Missing uk/{build_dir}/cmds-developerinterfaces.adoc

See original version for this content.

Механізм конфігурації

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

#
# A '#' or ';' character indicates a comment.
#

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

; user identity
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Різні команди зчитують дані з конфігураційного файлу та відповідно налаштовують свою роботу. Список та докладнішу інформацію про механізм конфігурації див. у git-config[1].

Термінологія ідентифікаторів

<object>

Вказує назву об’єкта для будь-якого типу об’єкта.

<blob>

Вказує ім’я об’єкта blob.

<tree>

Вказує назву об’єкта дерева.

<commit>

Вказує назву об’єкта коміту.

<tree-ish>

Вказує назву об’єкта дерева, коміту або тегу. Команда, яка приймає аргумент типу <tree-ish>, зрештою хоче працювати з об’єктом <tree>, але автоматично розіменовує об’єкти <commit> та <tag>, що вказують на <tree>.

<commit-ish>

Вказує назву об’єкта комміту або тегу. Команда, яка приймає аргумент типу <commit-ish>, зрештою хоче працювати з об’єктом <commit>, але автоматично розіменовує об’єкти <tag>, що вказують на <commit>.

<type>

Вказує на необхідність вказати тип об’єкта. Наразі це один із таких типів: blob, tree, commit або tag.

<file>

Вказує ім’я файлу — майже завжди відносно кореня деревоподібної структури, яку описує GIT_INDEX_FILE.

Символічні ідентифікатори

Будь-яка команда Git, яка приймає будь-який <object>, також може використовувати наступну символічну нотацію:

HEAD

вказує на керівника поточного відділення.

<tag>

коректний тег name (тобто посилання refs/tags/<tag>).

<head>

коректне ім’я заголовка (тобто посилання refs/heads/<заголовок>).

Для отримання повнішого списку способів написання назв об’єктів див. розділ «ВИЗНАЧЕННЯ РЕВІЗІЙ» у gitrevisions[7].

Структура файлів/каталогів

Будь ласка, перегляньте документ gitrepository-layout[5].

Більш детальну інформацію про кожен хук дивіться у githooks[5].

SCM вищого рівня можуть надавати та керувати додатковою інформацією в $GIT_DIR.

Термінологія

Будь ласка, дивіться gitglossary[7].

Змінні середовища

Різні команди Git звертають увагу на змінні середовища та змінюють їхню поведінку. Змінні середовища, позначені як "Boolean", приймають свої значення так само, як і змінні конфігурації з логічними значеннями, тобто "true", "yes", "on" та додатні числа приймаються як "yes", тоді як "false", "no", "off" та "0" приймаються як "no".

Ось змінні:

Система

HOME

Вказує шлях до домашнього каталогу користувача. У Windows, якщо не встановлено, Git встановить змінну середовища процесу, що дорівнює: $HOMEDRIVE$HOMEPATH, якщо існують обидві змінні, $HOMEDRIVE та $HOMEPATH; інакше $USERPROFILE, якщо $USERPROFILE існує.

Репозиторій Git

Ці змінні середовища застосовуються до «всіх» основних команд Git. Примітка: варто зазначити, що вони можуть бути використані/перевизначені SCMS, що працює над Git, тому будьте обережні, якщо використовуєте сторонній фронтенд.

GIT_INDEX_FILE

Ця змінна середовища вказує на альтернативний файл індексу. Якщо не вказано, використовується значення за замовчуванням $GIT_DIR/index.

GIT_INDEX_VERSION

Ця змінна середовища вказує, яка версія індексу використовується під час запису індексного файлу. Вона не вплине на існуючі індексні файли. За замовчуванням використовується версія індексного файлу 2 або 3. Див. git-update-index[1] для отримання додаткової інформації.

GIT_OBJECT_DIRECTORY

Якщо каталог для зберігання об’єктів вказано через цю змінну середовища, то каталоги sha1 створюються під ним, інакше використовується каталог за замовчуванням $GIT_DIR/objects.

GIT_ALTERNATE_OBJECT_DIRECTORIES

Через незмінну природу об’єктів Git, старі об’єкти можна архівувати у спільні каталоги лише для читання. Ця змінна визначає список каталогів об’єктів Git, розділений символами ":" (у Windows - ";"), які можна використовувати для пошуку об’єктів Git. Нові об’єкти не будуть записані в ці каталоги.

Записи, що починаються з " (подвійних лапок), будуть інтерпретовані як шляхи в лапках у стилі C, без початкових та кінцевих подвійних лапок та з урахуванням екранування зворотної склесної риски. Наприклад, значення "path-with-\"-and-:-in-it":vanilla-path має два шляхи: path-with-"-and-:-in-it та vanilla-path.

GIT_DIR

Якщо встановлено змінну середовища GIT_DIR, вона вказує шлях, який використовуватиметься замість стандартного .git для бази репозиторію. Параметр командного рядка --git-dir також встановлює це значення.

GIT_WORK_TREE

Встановіть шлях до кореня робочого дерева. Це також можна контролювати за допомогою параметра командного рядка --work-tree та змінної конфігурації core.worktree.

GIT_NAMESPACE

Встановіть простір імен Git; див. деталі у gitnamespaces[7]. Параметр командного рядка --namespace також встановлює це значення.

GIT_CEILING_DIRECTORIES

Це має бути список абсолютних шляхів, розділених двокрапками. Якщо встановлено, це список каталогів, до яких Git не повинен переходити за допомогою chdir під час пошуку каталогу репозиторію (корисно для виключення мережевих каталогів, що повільно завантажуються). Він не виключатиме поточний робочий каталог або GIT_DIR, встановлений у командному рядку або в середовищі. Зазвичай Git має прочитати записи в цьому списку та вирішити будь-яке символічне посилання, яке може бути присутнім, щоб порівняти їх з поточним каталогом. Однак, якщо навіть цей доступ повільний, ви можете додати порожній запис до списку, щоб повідомити Git, що наступні записи не є символічними посиланнями і їх не потрібно розв’язувати; наприклад, GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM

Під час запуску в каталозі, який не має каталогу репозиторію ".git", Git намагається знайти такий каталог у батьківських каталогах, щоб знайти вершину робочого дерева, але за замовчуванням він не перетинає межі файлової системи. Цю булеву змінну середовища можна встановити в значення true, щоб вказати Git не зупинятися на межах файлової системи. Як і GIT_CEILING_DIRECTORIES, це не вплине на явний каталог репозиторію, встановлений через GIT_DIR або в командному рядку.

GIT_COMMON_DIR

Якщо для цієї змінної встановлено шлях, файли, що не належать до робочого дерева та зазвичай знаходяться в $GIT_DIR, будуть взяті з цього шляху. Файли, специфічні для робочого дерева, такі як HEAD або index, беруться з $GIT_DIR. Див. gitrepository-layout[5] та git-worktree[1] для отримання детальної інформації. Ця змінна має нижчий пріоритет, ніж інші змінні шляху, такі як GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY…​

GIT_DEFAULT_HASH

Якщо цю змінну встановлено, алгоритм хешування за замовчуванням для нових репозиторіїв буде встановлено на це значення. Це значення ігнорується під час клонування, і завжди використовуються налаштування віддаленого репозиторію. Значення за замовчуванням — "sha1". Див. --object-format у git-init[1].

GIT_DEFAULT_REF_FORMAT

Якщо цю змінну встановлено, формат посилань на серверну частину за замовчуванням для нових репозиторіїв буде встановлено на це значення. Значення за замовчуванням — "файли". Див. --ref-format у git-init[1].

Коміти Git

GIT_AUTHOR_NAME

Зрозуміле для людини ім’я, яке використовується в ідентифікації автора під час створення об’єктів комітів або тегів, або під час написання рефлогів. Замінює налаштування конфігурації user.name та author.name.

GIT_AUTHOR_EMAIL

Адреса електронної пошти, що використовується в ідентифікації автора під час створення об’єктів комітів або тегів, або під час написання рефлогів. Замінює налаштування конфігурації user.email та author.email.

GIT_AUTHOR_DATE

Дата, що використовується для ідентифікації автора під час створення об’єктів комітів або тегів, або під час написання рефлогів. Див. git-commit[1] для коректних форматів.

GIT_COMMITTER_NAME

Зрозуміле для людини ім’я, яке використовується в ідентифікації комітера під час створення об’єктів комітів або тегів, або під час написання рефлогів. Замінює налаштування конфігурації user.name та committer.name.

GIT_COMMITTER_EMAIL

Адреса електронної пошти, що використовується в ідентифікації автора під час створення об’єктів комітів або тегів, або під час написання рефлогів. Замінює налаштування конфігурації user.email та committer.email.

GIT_COMMITTER_DATE

Дата, що використовується для ідентифікації комітера під час створення об’єктів комітів або тегів, або під час написання рефлогів. Див. git-commit[1] для коректних форматів.

EMAIL

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

Різниці в Git

GIT_DIFF_OPTS

Єдиним допустимим параметром є "--unified=??" або "-u??", щоб встановити кількість рядків контексту, що відображаються під час створення уніфікованого різниці. Це має пріоритет над будь-яким значенням опції "-U" або "--unified", переданим у командному рядку Git diff.

GIT_EXTERNAL_DIFF

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

шлях до старого файлу старий шістнадцятковий старий режим новий файл новий шістнадцятковий новий режим

де:

<old|new>-file

файли, які GIT_EXTERNAL_DIFF може використовувати для читання вмісту <old|new>,

<old|new>-hex

є 40-шістнадцятковими хешами SHA-1,

<old|new>-mode

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

Параметри файлу можуть вказувати на робочий файл користувача (наприклад, new-file у "git-diff-files"), /dev/null (наприклад, old-file, коли додається новий файл) або тимчасовий файл (наприклад, old-file в індексі). GIT_EXTERNAL_DIFF не повинен турбуватися про від’єднання тимчасового файлу — він видаляється, коли GIT_EXTERNAL_DIFF завершує роботу.

Для шляху, що не об’єднаний, викликається GIT_EXTERNAL_DIFF з 1 параметром, <шлях>.

Для кожного викликаного шляху GIT_EXTERNAL_DIFF встановлюються дві змінні середовища: GIT_DIFF_PATH_COUNTER та GIT_DIFF_PATH_TOTAL.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

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

GIT_DIFF_PATH_COUNTER

Лічильник, що базується на 1, збільшується на одиницю для кожного шляху.

GIT_DIFF_PATH_TOTAL

Загальна кількість шляхів.

інший

GIT_MERGE_VERBOSITY

Число, що контролює обсяг виводу, що відображається рекурсивною стратегією злиття. Перевизначає merge.verbosity. Див. git-merge[1]

GIT_PAGER

Ця змінна середовища перевизначає $PAGER. Якщо їй встановлено значення порожнього рядка або значення "cat", Git не запустить пейджер. Дивіться також опцію core.pager у git-config[1].

GIT_PROGRESS_DELAY

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

GIT_EDITOR

Ця змінна середовища перевизначає $EDITOR та $VISUAL. Вона використовується кількома командами Git, коли в інтерактивному режимі потрібно запустити редактор. Див. також git-var[1] та опцію core.editor у git-config[1].

GIT_SEQUENCE_EDITOR

Ця змінна середовища перевизначає налаштований редактор Git під час редагування списку справ інтерактивного перебазування. Див. також git-rebase[1] та опцію sequence.editor у git-config[1].

GIT_SSH
GIT_SSH_COMMAND

Якщо будь-яка з цих змінних середовища встановлена, то git fetch та git push використовуватимуть зазначену команду замість ssh, коли їм потрібно буде підключитися до віддаленої системи. Параметри командного рядка, що передаються налаштованій команді, визначаються варіантом ssh. Дивіться опцію ssh.variant у git-config[1] для отримання детальної інформації.

$GIT_SSH_COMMAND має пріоритет над $GIT_SSH та інтерпретується оболонкою, що дозволяє додавати додаткові аргументи. $GIT_SSH, з іншого боку, має бути лише шляхом до програми (яка може бути скриптом оболонки, якщо потрібні додаткові аргументи).

Зазвичай простіше налаштувати будь-які потрібні опції через ваш особистий файл .ssh/config. Будь ласка, зверніться до документації ssh для отримання додаткової інформації.

GIT_SSH_VARIANT

Якщо цю змінну середовища встановлено, вона перевизначає автоматичне визначення Git, чи посилаються GIT_SSH/GIT_SSH_COMMAND/core.sshCommand на OpenSSH, plink чи tortoiseplink. Ця змінна перевизначає налаштування конфігурації ssh.variant, яке виконує ту саму функцію.

GIT_SSL_NO_VERIFY

Встановлення та експорт цієї змінної середовища до будь-якого значення повідомляє Git, що не потрібно перевіряти SSL-сертифікат під час отримання або надсилання через HTTPS.

GIT_ATTR_SOURCE

Встановлює деревоподібну структуру, з якої будуть зчитуватися атрибути gitattributes.

GIT_ASKPASS

Якщо цю змінну середовища встановлено, то команди Git, яким потрібно отримати паролі або парольні фрази (наприклад, для автентифікації HTTP або IMAP), викличуть цю програму з відповідним запитом як аргументом командного рядка та зчитають пароль з її STDOUT. Дивіться також опцію core.askPass у git-config[1].

GIT_TERMINAL_PROMPT

Якщо для цієї булевої змінної середовища встановлено значення false, git не виводитиме запити в терміналі (наприклад, під час запиту HTTP-автентифікації).

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

Беріть конфігурацію з заданих файлів, а не з глобальних або системних файлів конфігурації. Якщо встановлено GIT_CONFIG_SYSTEM, файл конфігурації системи, визначений під час збірки (зазвичай /etc/gitconfig), не буде зчитуватися. Аналогічно, якщо встановлено GIT_CONFIG_GLOBAL, ні $HOME/.gitconfig, ні $XDG_CONFIG_HOME/git/config не будуть зчитуватися. Можна встановити значення /dev/null, щоб пропустити зчитування файлів конфігурації відповідного рівня.

GIT_CONFIG_NOSYSTEM

Чи слід пропускати зчитування налаштувань із загальносистемного файлу $(prefix)/etc/gitconfig. Цю булеву змінну середовища можна використовувати разом із $HOME та $XDG_CONFIG_HOME для створення передбачуваного середовища для вимогливого скрипта, або ж встановити для неї значення true, щоб тимчасово уникнути використання файлу /etc/gitconfig з помилками, поки хтось із достатніми правами виправить це.

GIT_FLUSH

Якщо для цієї булевої змінної середовища встановлено значення true, то такі команди, як git blame (у поступовому режимі), git rev-list, git log, git check-attr та git check-ignore, примусово очищатимуть вихідний потік після очищення кожного запису. Якщо для цієї змінної встановлено значення false, вивід цих команд буде виконуватися з використанням повністю буферизованого вводу-виводу. Якщо цю змінну середовища не встановлено, Git вибере буферизоване або орієнтоване на записи очищення залежно від того, чи перенаправляється stdout до файлу чи ні.

GIT_TRACE

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

Якщо для цієї змінної встановлено значення "1", "2" або "true" (порівняння не враховує регістр), повідомлення трасування будуть виведені на stderr.

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

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

Скасування значення змінної або встановлення для неї порожнього значення, "0" або "false" (без урахування регістру) вимикає повідомлення трасування.

GIT_TRACE_FSMONITOR

Вмикає повідомлення трасування для розширення монітора файлової системи. Див. GIT_TRACE для отримання доступних параметрів виводу трасування.

GIT_TRACE_PACK_ACCESS

Вмикає повідомлення трасування для всіх звернень до будь-яких пакетів. Для кожного звернення записується ім’я файлу пакета та зміщення в пакеті. Це може бути корисним для усунення деяких проблем продуктивності, пов’язаних з пакетом. Див. GIT_TRACE для отримання інформації про доступні параметри виводу трасування.

GIT_TRACE_PACKET

Вмикає повідомлення трасування для всіх пакетів, що надходять або виходять з певної програми. Це може допомогти з налагодженням узгодження об’єктів або іншими проблемами протоколу. Трасування вимикається для пакета, що починається з "PACK" (але див. GIT_TRACE_PACKFILE нижче). Див. GIT_TRACE для доступних параметрів виводу трасування.

GIT_TRACE_PACKFILE

Дозволяє трасувати пакетні файли, надіслані або отримані певною програмою. На відміну від інших виводів трасування, це трасування є дослівним: без заголовків і без цитування двійкових даних. Ви майже напевно захочете направити його у файл (наприклад, GIT_TRACE_PACKFILE=/tmp/my.pack), а не відображати його в терміналі чи змішувати з іншими виводами трасування.

Зверніть увагу, що наразі це реалізовано лише для клієнтської частини клонів та вибірок.

GIT_TRACE_PERFORMANCE

Вмикає трасування повідомлень, пов’язаних із продуктивністю, наприклад, загальний час виконання кожної команди Git. Див. GIT_TRACE для отримання доступних параметрів трасування.

GIT_TRACE_REFS

Вмикає повідомлення трасування для операцій з базою даних посилань. Див. GIT_TRACE для отримання доступних параметрів виводу трасування.

GIT_TRACE_SETUP

Дозволяє виводити повідомлення трасування .git, робоче дерево та поточний робочий каталог після завершення фази налаштування Git. Див. GIT_TRACE для доступних параметрів виводу трасування.

GIT_TRACE_SHALLOW

Вмикає повідомлення трасування, які можуть допомогти налагоджувати вибірку/клонування поверхневих репозиторіїв. Див. GIT_TRACE для доступних параметрів виводу трасування.

GIT_TRACE_CURL

Вмикає повний дамп трасування curl для всіх вхідних та вихідних даних, включаючи описову інформацію, транспортного протоколу git. Це схоже на виконання curl --trace-ascii у командному рядку. Див. GIT_TRACE для доступних параметрів виводу трасування.

GIT_TRACE_CURL_NO_DATA

Коли ввімкнено трасування curl (див. GIT_TRACE_CURL вище), не виводьте дані (тобто виводьте лише інформаційні рядки та заголовки).

GIT_TRACE2

Дозволяє отримувати детальніші повідомлення трасування з бібліотеки "trace2". Вивід з GIT_TRACE2 — це простий текстовий формат для зручності читання людиною.

Якщо для цієї змінної встановлено значення "1", "2" або "true" (порівняння не враховує регістр), повідомлення трасування будуть виведені на stderr.

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

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

Крім того, якщо змінна має значення af_unix:[<тип-сокета>:]<абсолютний-шлях>, Git спробує відкрити шлях як Unix Domain Socket. Тип сокета може бути stream або dgram.

Скасування значення змінної або встановлення для неї порожнього значення, "0" або "false" (без урахування регістру) вимикає повідомлення трасування.

Див. документація Trace2 для отримання повної інформації.

GIT_TRACE2_EVENT

Цей параметр записує дані у форматі JSON, який підходить для машинної інтерпретації. Див. GIT_TRACE2 для отримання доступних параметрів виводу трасування та документація Trace2 для отримання повної інформації.

GIT_TRACE2_PERF

Окрім текстових повідомлень, доступних у GIT_TRACE2, цей параметр записує формат на основі стовпців для розуміння вкладених областей. Див. GIT_TRACE2 для отримання інформації про доступні параметри виводу трасування та документація Trace2 для отримання повної інформації.

GIT_TRACE_REDACT

За замовчуванням, коли трасування активовано, Git видаляє значення файлів cookie, заголовків "Authorization:", "Proxy-Authorization:" та URI packfile. Встановіть для цієї логічної змінної середовища значення false, щоб запобігти цьому видаленню.

GIT_NO_REPLACE_OBJECTS

Встановлення та експорт цієї змінної середовища вказує Git ігнорувати посилання на заміну та не замінювати об’єкти Git.

GIT_LITERAL_PATHSPECS

Встановлення цієї логічної змінної середовища в значення true призведе до того, що Git трактуватиме всі специфікації шляхів буквально, а не як шаблони глобальних змінних. Наприклад, виконання команди GIT_LITERAL_PATHSPECS=1 git log -- *.c' шукатиме коміти, що стосуються шляху *.c, а не будь-які шляхи, яким відповідає глобальний змінний *.c. Вам може знадобитися це, якщо ви передаєте буквальні шляхи до Git (наприклад, шляхи, раніше надані вам за допомогою git ls-tree, вивід --raw diff тощо).

GIT_GLOB_PATHSPECS

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

GIT_NOGLOB_PATHSPECS

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

GIT_ICASE_PATHSPECS

Якщо встановити для цієї логічної змінної середовища значення true, Git трактуватиме всі специфікації шляхів як нечутливі до регістру.

GIT_NO_LAZY_FETCH

Встановлення цієї логічної змінної середовища на значення true повідомляє Git, що він не буде ліниво отримувати відсутні об’єкти з віддаленого сервера-промісника на вимогу.

GIT_REFLOG_ACTION

Коли посилання оновлюється, записи в журналі посилань створюються для відстеження причини оновлення посилання (зазвичай це назва команди верхнього рівня, яка оновила посилання), на додаток до старих та нових значень посилання. Скриптована команда Porcelain може використовувати допоміжну функцію set_reflog_action у git-sh-setup, щоб встановити свою назву для цієї змінної, коли вона викликається кінцевим користувачем як команда верхнього рівня, для запису в тілі журналу посилань.

GIT_REF_PARANOIA

Якщо для цієї булевої змінної середовища встановлено значення false, ігноруйте пошкоджені або неправильно названі посилання під час ітерації по списках посилань. Зазвичай Git намагатиметься включити будь-які такі посилання, що може призвести до збою деяких операцій. Зазвичай це краще, оскільки потенційно деструктивні операції (наприклад, git-prune[1]) краще переривати, ніж ігнорувати пошкоджені посилання (і таким чином вважати історію, на яку вони вказують, невартою збереження). Значення за замовчуванням — 1 (тобто, варто побоюватися виявлення та переривання всіх операцій). Зазвичай вам не потрібно встановлювати це значення на 0, але це може бути корисним під час спроби врятувати дані з пошкодженого репозиторію.

GIT_COMMIT_GRAPH_PARANOIA

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

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

GIT_ALLOW_PROTOCOL

Якщо встановлено список протоколів, розділених двокрапками, поводитися так, ніби protocol.allow встановлено на never, і для кожного зі перелічених протоколів protocol.<name>.allow встановлено на always (замінюючи будь-яку існуючу конфігурацію). Див. опис protocol.allow у git-config[1] для отримання додаткової інформації.

GIT_PROTOCOL_FROM_USER

Встановіть цю булеву змінну середовища на значення false, щоб запобігти використанню протоколів fetch/push/clone, які налаштовані на стан user. Це корисно для обмеження рекурсивної ініціалізації підмодулів з ненадійного репозиторію або для програм, які передають потенційно ненадійні URL-адреси командам git. Див. git-config[1] для отримання додаткової інформації.

GIT_PROTOCOL

Тільки для внутрішнього використання. Використовується для встановлення зв’язку з протоколом Wire. Містить список ключів, розділених двокрапкою :, з необов’язковими значеннями <ключ>[=<значення>]. Наявність невідомих ключів та значень слід ігнорувати.

Зверніть увагу, що сервери можуть потребувати налаштування, щоб дозволити цій змінній передавати дані через деякі транспортні канали. Вона буде поширюватися автоматично під час доступу до локальних репозиторіїв (тобто file:// або шлях файлової системи), а також через протокол git://. Для git-over-http це має працювати автоматично в більшості конфігурацій, але див. обговорення в git-http-backend[1]. Для git-over-ssh ssh-сервер може потребувати налаштування, щоб дозволити клієнтам передавати цю змінну (наприклад, використовуючи AcceptEnv GIT_PROTOCOL з OpenSSH).

Ця конфігурація необов’язкова. Якщо змінну не поширювати, клієнти повернуться до оригінального протоколу "v0" (але можуть втратити деякі покращення продуктивності або функції). Ця змінна наразі впливає лише на клони та вибірки; вона ще не використовується для надсилання (але може використовується в майбутньому).

GIT_OPTIONAL_LOCKS

Якщо для цієї булевої змінної середовища встановлено значення false, Git виконає будь-яку запитувану операцію без виконання будь-яких необов’язкових підоперацій, які потребують блокування. Наприклад, це запобіжить оновленню індексу git status як побічний ефект. Це корисно для процесів, що працюють у фоновому режимі та не хочуть спричиняти конфлікт блокувань з іншими операціями в репозиторії. За замовчуванням 1.

GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR

Тільки для Windows: дозволяє перенаправлення стандартних дескрипторів вводу/виводу/помилок на шляхи, визначені змінними середовища. Це особливо корисно в багатопотокових застосунках, де канонічний спосіб передачі стандартних дескрипторів через CreateProcess() не є варіантом, оскільки це вимагатиме, щоб дескриптори були позначені як успадковувані (і, як наслідок, кожен породжений процес успадковуватиме їх, можливо, блокуючи звичайні операції Git). Основним цільовим варіантом використання є використання іменованих каналів для зв’язку (наприклад, \\.\pipe\my-git-stdin-123).

Підтримуються два спеціальні значення: off просто закриє відповідний стандартний дескриптор, а якщо GIT_REDIRECT_STDERR дорівнює 2>&1, стандартна помилка буде перенаправлена на той самий дескриптор, що й стандартний вивід.

GIT_PRINT_SHA1_ELLIPSIS (застарілий)

Якщо встановлено значення yes, вивести три крапки після (скороченого) значення SHA-1. Це впливає на індикацію відокремлених HEAD (git-checkout[1]) та необроблений вивід diff (git-diff[1]). Виведення трикрапки у згаданих випадках більше не вважається адекватним, і його підтримка, ймовірно, буде видалена в найближчому майбутньому (разом зі змінною).

GIT_ADVICE

Якщо встановлено значення 0, то вимкніть усі повідомлення з порадами. Ці повідомлення призначені для надання підказок користувачам, які можуть допомогти їм вийти з проблемних ситуацій або скористатися новими функціями. Користувачі можуть вимикати окремі повідомлення за допомогою ключів конфігурації advice.*. Ці повідомлення можуть заважати інструментам, що виконують процеси Git, тому ця змінна доступна для вимкнення повідомлень. (Глобальний параметр --no-advice також доступний, але старі версії Git можуть не працювати, якщо цей параметр не зрозумілий. Змінна середовища буде ігноруватися версіями Git, які її не розуміють.)

Обговорення

Більш детальну інформацію про наступне можна знайти за розділ посібника користувача про концепції Git та gitcore-tutorial[7].

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

База даних об’єктів містить об’єкти трьох основних типів: блоби, які зберігають дані файлів; дерева, які вказують на блоби та інші дерева для побудови ієрархій каталогів; та коміти, кожен з яких посилається на одне дерево та певну кількість батьківських комітів.

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

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

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

Іменовані вказівники, які називаються посиланнями (refs), позначають цікаві моменти в історії. Посилання може містити SHA-1-ім’я об’єкта або ім’я іншого посилання (останнє називається "символічним посиланням"). Посилання з іменами, що починаються з refs/head/, містять SHA-1-ім’я останнього коміту (або "head") гілки, що розробляється. SHA-1-імена тегів, що цікавлять, зберігаються в refs/tags/. Символічне посилання з іменем HEAD містить ім’я поточної витягнутої гілки.

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

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

БЕЗПЕКА

Деякі параметри конфігурації та файли перехоплень можуть призвести до запуску Git довільних команд оболонки. Оскільки конфігурація та перехоплення не копіюються за допомогою git clone, загалом безпечно клонувати віддалені репозиторії з ненадійним вмістом, перевіряти їх за допомогою git log тощо.

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

За замовчуванням Git відмовиться запускатися, якщо репозиторій належить комусь іншому, ніж користувач, який виконує команду. Див. запис safe.directory у git-config[1]. Хоча це може допомогти захистити вас у багатокористувацькому середовищі, зверніть увагу, що ви також можете отримати ненадійні репозиторії, які належать вам (наприклад, якщо ви розпакуєте zip-файл або tar-архів з ненадійного джерела). У таких випадках вам спочатку потрібно буде "очистити" ненадійний репозиторій.

Якщо у вас є ненадійний каталог .git, спочатку слід клонувати його за допомогою git clone --no-local, щоб отримати чисту копію. Git обмежує набір опцій та перехоплювачів, які будуть виконуватися upload-pack, що обробляє серверну частину клону або fetch, але майте на увазі, що область поверхні для атаки на upload-pack велика, тому це несе певний ризик. Найбезпечніше — обслуговувати репозиторій як непривілейований користувач (або через git-daemon[1], ssh, або використовуючи інші інструменти для зміни ідентифікаторів користувачів). Дивіться обговорення в розділі БЕЗПЕКА у git-upload-pack[1].

ДОДАТКОВА ДОКУМЕНТАЦІЯ

Дивіться посилання в розділі «опис», щоб розпочати роботу з Git. Наведена нижче інформація, ймовірно, містить більше деталей, ніж потрібно для користувача-початківця.

У розділах розділ про концепції Git у посібнику користувача та gitcore-tutorial[7] наведено вступ до базової архітектури Git.

Див. огляд рекомендованих робочих процесів у gitworkflows[7].

Дивіться також документи за howto для отримання корисних прикладів.

Внутрішня документація описана за Документація Git API.

Користувачам, які мігрують з CVS, також може бути цікаво прочитати gitcvs-migration[7].

Автори

Git був започаткований Лінусом Торвальдсом, а наразі його підтримує Джуніо К. Хамано. Численні внески надійшли зі списку розсилки Git <git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary надає вам повніший список учасників.

Якщо у вас є клон самого git.git, вивід git-shortlog[1] та git-blame[1] може показати вам авторів певних частин проєкту.

Повідомлення про помилки

Повідомляйте про помилки до списку розсилки Git <git@vger.kernel.org>, де в основному здійснюється розробка та підтримка. Вам не потрібно бути підписаним на список, щоб надіслати туди повідомлення. Перегляньте архів списку розсилки за адресою https://lore.kernel.org/git, щоб переглянути попередні звіти про помилки та інші обговорення.

Проблеми, що стосуються безпеки, слід повідомляти приватно до списку розсилки Git Security <git-security@googlegroups.com>.

ДИВ. ТАКОЖ

gittutorial[7], gittutorial-2[7], giteveryday[7], gitcvs-migration[7], gitglossary[7], gitcore-tutorial[7], gitcli[7], Посібник користувача Git, gitworkflows[7]

GIT

Частина набору git[1]