Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.50.1 → 2.51.0 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.47.1 → 2.47.3 no changes
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.4 no changes
-
2.46.0
2024-07-29
- 2.45.2 → 2.45.4 no changes
-
2.45.1
2024-04-29
-
2.45.0
2024-04-29
- 2.44.2 → 2.44.4 no changes
-
2.44.1
2024-04-19
-
2.44.0
2024-02-23
- 2.43.5 → 2.43.7 no changes
-
2.43.4
2024-04-19
- 2.43.2 → 2.43.3 no changes
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.42.3 → 2.42.4 no changes
-
2.42.2
2024-04-19
-
2.42.1
2023-11-02
-
2.42.0
2023-08-21
- 2.41.2 → 2.41.3 no changes
-
2.41.1
2024-04-19
-
2.41.0
2023-06-01
- 2.40.3 → 2.40.4 no changes
-
2.40.2
2024-04-19
- 2.40.1 no changes
- 2.40.0 no changes
- 2.39.5 no changes
-
2.39.4
2024-04-19
- 2.39.1 → 2.39.3 no changes
-
2.39.0
2022-12-12
- 2.38.3 → 2.38.5 no changes
-
2.38.2
2022-12-11
- 2.38.1 no changes
-
2.38.0
2022-10-02
- 2.37.3 → 2.37.7 no changes
-
2.37.2
2022-08-11
- 2.37.1 no changes
-
2.37.0
2022-06-27
- 2.36.1 → 2.36.6 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 no changes
-
2.34.0
2021-11-15
- 2.33.3 → 2.33.8 no changes
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
- 2.32.1 → 2.33.0 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 no changes
-
2.26.0
2020-03-22
- 2.25.2 → 2.25.5 no changes
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 no changes
-
2.23.0
2019-08-16
- 2.22.2 → 2.22.5 no changes
-
2.22.1
2019-08-11
-
2.22.0
2019-06-07
- 2.20.1 → 2.21.4 no changes
-
2.20.0
2018-12-09
- 2.19.3 → 2.19.6 no changes
-
2.19.2
2018-11-21
- 2.19.1 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
- 2.13.7 no changes
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
СИНОПСИС
git [-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 See original version for this content. |
Допоміжні команди
Маніпулятори:
Warning
|
Missing See original version for this content. |
Слідчі:
Warning
|
Missing See original version for this content. |
Взаємодія з іншими
Ці команди призначені для взаємодії із зовнішнім SCM та з іншими людьми через патч через електронну пошту.
Warning
|
Missing 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 See original version for this content. |
Команди допиту
Warning
|
Missing See original version for this content. |
Загалом, команди запиту не стосуються файлів у робочому дереві.
Синхронізація репозиторіїв
Warning
|
Missing See original version for this content. |
Нижче наведено допоміжні команди, що використовуються вищезазначеними; кінцеві користувачі зазвичай не використовують їх безпосередньо.
Warning
|
Missing See original version for this content. |
Путівники
Наведені нижче сторінки документації є посібниками з концепцій Git.
Warning
|
Missing See original version for this content. |
Інтерфейси репозиторію, команд та файлів
У цій документації обговорюються інтерфейси репозиторію та команд, з якими користувачі повинні безпосередньо взаємодіяти. Див. --user-formats
у git-help[1] для отримання додаткової інформації про критерії.
Warning
|
Missing See original version for this content. |
Формати файлів, протоколи та інші інтерфейси розробника
У цій документації обговорюються формати файлів, протоколи OTP та інші інтерфейси розробника git. Див. --developer-interfaces
у git-help[1].
Warning
|
Missing 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>, також може використовувати наступну символічну нотацію:
Для отримання повнішого списку способів написання назв об’єктів див. розділ «ВИЗНАЧЕННЯ РЕВІЗІЙ» у gitrevisions[7].
Структура файлів/каталогів
Будь ласка, перегляньте документ gitrepository-layout[5].
Більш детальну інформацію про кожен хук дивіться у githooks[5].
SCM вищого рівня можуть надавати та керувати додатковою інформацією в $GIT_DIR
.
Термінологія
Будь ласка, дивіться gitglossary[7].
Змінні середовища
Різні команди Git звертають увагу на змінні середовища та змінюють їхню поведінку. Змінні середовища, позначені як "Boolean", приймають свої значення так само, як і змінні конфігурації з логічними значеннями, тобто "true", "yes", "on" та додатні числа приймаються як "yes", тоді як "false", "no", "off" та "0" приймаються як "no".
Ось змінні:
Репозиторій 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>.
GIT
Частина набору git[1]