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

НАЗВА

git-commit — Запис змін до репозиторію

СИНОПСИС

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
	   [--dry-run] <commit>]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])…​] [-S[<keyid>]]
	   [--] [<pathspec>…​]

ОПИС

Створює новий коміт, що містить поточний вміст індексу та вказане повідомлення журналу з описом змін. Новий коміт є прямим дочірнім елементом HEAD, зазвичай це вершина поточної гілки, і гілка оновлюється, щоб вказувати на неї (якщо жодна гілка не повʼязана з робочим деревом, у цьому випадку HEAD "відокремлюється", як описано в git-checkout[1]).

Вміст, який потрібно зафіксувати, можна вказати кількома способами:

  1. використовуючи git-add[1] для поступового "додавання" змін до індексу перед використанням команди commit (Примітка: навіть змінені файли необхідно "додавати");

  2. використовуючи git-rm[1] для видалення файлів з робочого дерева та індексу, знову ж таки перед використанням команди commit;

  3. шляхом перерахування файлів як аргументів команди commit (без параметрів --interactive або --patch), і в цьому випадку коміт ігноруватиме зміни, поміщені в індекс, і натомість записуватиме поточний вміст перелічених файлів (який вже має бути відомий Git);

  4. використовуючи ключ -a з командою commit для автоматичного "додавання" змін з усіх відомих файлів (тобто всіх файлів, які вже перелічені в індексі) та автоматичного "збереження" файлів в індексі, які були видалені з робочого дерева, а потім виконати фактичне внесення змін;

  5. використовуючи перемикачі --interactive або --patch з командою commit, щоб по черзі вирішувати, які файли або фрагменти мають бути частиною коміту на додачу до вмісту індексу, перед завершенням операції. Дивіться розділ «Інтерактивний режим»' у git-add[1], щоб дізнатися, як керувати цими режимами.

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

Якщо ви зробите коміт, а потім одразу після цього знайдете помилку, ви можете виправити її за допомогою git reset.

ОПЦІЇ

-a
--all

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

-p
--patch

Використовуйте інтерактивний інтерфейс вибору латок, щоб вибрати зміни для фіксації. Див. git-add[1] для отримання детальної інформації.

-U<n>
--unified=<n>

Створює файли відмінностей (diff) з <n> рядками контексту. Стандартно використовується diff.context або 3, якщо параметр конфігурації не встановлено.

--inter-hunk-context=<n>

Показує контекст між фрагментами відмінностей (diff hunks), до вказаної <кількості> рядків, таким чином обʼєднуючи фрагменти, що знаходяться близько один до одного. Стандартно використовується значення diff.interHunkContext або 0, якщо параметр конфігурації не встановлено.

-C <коміт>
--reuse-message=<коміт>

Використання наявного обʼєкта <commit> та повторне використання повідомлення журналу та інформації про авторство (включно з позначкою часу) під час створення коміту.

-c <коміт>
--reedit-message=<коміт>

Як і -C, але з -c викликається редактор, щоб користувач міг додатково редагувати повідомлення коміту.

--fixup=[(amend|reword):]<commit>

Створення нового коміту, який "виправляє" <commit> при застосуванні з git rebase --autosquash. Звичайний --fixup=<commit> створює коміт "fixup!", який змінює вміст <commit>, але залишає його повідомлення журналу недоторканим. --fixup=amend:<commit> подібний, але створює коміт "amend!", який також замінює повідомлення журналу <commit> на повідомлення журналу коміту "amend!". --fixup=reword:<commit> створює коміт "amend!", який замінює повідомлення журналу <commit> на своє власне повідомлення журналу, але не вносить змін до вмісту <commit>.

Коміт, створений простим параметром --fixup=<commit>, має заголовок, що складається з "fixup!", за яким йде заголовок <commit>, і розпізнається спеціально параметром git rebase --autosquash. Опцію -m можна використовувати для доповнення повідомлення журналу створеного коміту, але додатковий коментар буде видалено, як тільки коміт "fixup!" буде втиснутий у <commit> параметром git rebase --autosquash.

Коміт, створений за допомогою --fixup=amend:<commit>, схожий, але його заголовок має префікс "amend!". Повідомлення журналу <commit> копіюється в повідомлення журналу коміту "amend!" та відкривається в редакторі для уточнення. Коли git rebase --autosquash стискає коміт "amend!" в <commit>, повідомлення журналу <commit> замінюється уточненим повідомленням журналу з коміту "amend!". Якщо повідомлення журналу коміту "amend!" порожнє, це помилка, якщо не вказано --allow-empty-message.

--fixup=reword:<commit> — це скорочення від --fixup=amend:<commit> --only. Він створює коміт "amend!" лише з повідомленням журналу (ігноруючи будь-які зміни, внесені до індексу). При стисканні за допомогою git rebase --autosquash він замінює повідомлення журналу <commit> без внесення будь-яких інших змін.

Ні коміти "fixup!", ні "amend!" не змінюють авторство <commit>, якщо їх застосувати за допомогою git rebase --autosquash. Див. git-rebase[1] для отримання детальної інформації.

--squash=<коміт>

Створіть повідомлення коміту для використання з git rebase --autosquash. Заголовок повідомлення коміту береться з вказаного коміту з префіксом "squash!". Можна використовувати з додатковими опціями повідомлення коміту (-m/-c/-C/-F). Див. git-rebase[1] для отримання детальної інформації.

--reset-author

При використанні з опціями -C/-c/--amend, або під час коміту після конфліктного копіювання коміту (cherry-pick), оголошує, що авторство результуючого коміту тепер належить коміттеру. Це також поновлює позначку часу автора.

--short

Під час пробного запуску надає результат у скороченому форматі. Див. git-status[1] для отримання детальної інформації. Має на увазі --dry-run.

--branch

Показує інформацію про гілку та відстеження навіть у скороченому форматі. Див. git-status[1] для отримання детальної інформації.

--porcelain

Під час пробного запуску надайте результат у форматі, готовому для роботи з porcelain. Див. git-status[1] для отримання детальної інформації. Мається на увазі --dry-run.

--long

Під час пробного запуску виводить дані у довгому форматі. Це стандартний формат виводу для git-status[1]. Мається на увазі --dry-run.

-z
--null

Під час виведення виводу short або porcelain git-status[1], виводить дослівно назву файлу та завершує записи символами NUL замість LF. Якщо формат не вказано, мається на увазі формат виводу --porcelain. Без опції -z імена файлів з "незвичайними" символами взяті в лапки, як пояснено для змінної конфігурації core.quotePath (див. git-config[1]).

-F <файл>
--file=<файл>

Бере повідомлення коміту з <файл>. Використовуйте -, щоб прочитати повідомлення зі стандартного вводу.

--author=<автор>

Перевизначення автора коміту. Вкажіть явно автора, використовуючи стандартний формат A U Thor <author@example.com>. В іншому випадку <author> вважається шаблоном і використовується для пошуку наявного коміту від цього автора (тобто git rev-list --all -i --author=<author>); автор коміту потім копіюється з першого знайденого такого коміту.

--date=<дата>

Перевизначити дату авторства, яка використовується в коміті.

-m <msg>
--message=<повідомлення>

Використовуйте <msg> як повідомлення коміту. Якщо задано кілька опцій -m, їхні значення обʼєднуються в окремі абзаци.

Опція -m несумісна з -c, -C та -F.

-t <файл>
--template=<файл>

Під час редагування повідомлення коміту запустить редактор із вмістом <файл>. Змінна конфігурації commit.template часто використовується для неявно наданої команді цієї опції. Цей механізм може бути використаний проєктами, які хочуть надавати учасникам підказки щодо того, що писати в повідомленні та в якому порядку. Якщо користувач виходить з редактора, не редагуючи повідомлення, створення коміту переривається. Не має значення, коли повідомлення надається іншими способами, наприклад, за допомогою опцій -m або -F.

-s
--signoff
--no-signoff

Додає наприкінці повідомлення журналу коміту підпис Signed-off-by, поставлений автором коміту. Значення такого підпису залежить від проєкту, до якого ви робите коміт. Наприклад, він може підтверджувати, що автор коміту має права на публікацію роботи відповідно до ліцензії проєкту або погоджується з певними запевненнями щодо авторів, такими як «Сертифікат походження розробника». (Див. https://un5j2j18xhuv3q2cxb95nbb49yug.julianrbryant.com, щоб ознайомитися з тим, що використовується в ядрі Linux та проектах Git.) Зверніться до документації або керівництва проєкту, до якого ви робите внесок, щоб зрозуміти, як підписи використовуються в цьому проєкті.

Опцію --no-signoff можна використовувати для скасування попередньої опції --signoff у командному рядку.

У Git немає (і не буде) змінної конфігурації, яка б стандартно вмикала опцію командного рядка --signoff; детальніше див. елемент commit.signoff у gitfaq[7].

--trailer <token>[(=|:)<value>]

Вкажіть пару (<токен>, <значення>), яку слід застосувати як трейлер. (наприклад, git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>" додасть трейлер Signed-off-by та трейлер Helped-by до повідомлення коміту). Змінні конфігурації trailer.* (git-interpret-trailers[1]) можна використовувати для визначення того, чи пропущено дубльований трейлер, де в рядку трейлерів зʼявиться кожен трейлер та інші деталі.

-n
--verify
--no-verify

Оминає гачки pre-commit та commit-msg. Див. також githooks[5].

--allow-empty

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

--allow-empty-message

Створює коміт з порожнім повідомленням коміту без використання команд plumbing, таких як git-commit-tree[1]. Як і --allow-empty, ця команда в основному призначена для використання сторонніми скриптами інтерфейсу SCM.

--cleanup=<режим>

Визначає, як надане повідомлення коміту слід очистити перед комітом. <mode> може мати значення strip, whitespace, verbatim, scissors або default.

strip

Видаляє початкові та кінцеві порожні рядки, кінцеві пробіли, коментарі та згортає послідовні порожні рядки.

whitespace

Те саме, що й strip, але #коментарі не видаляються.

verbatim

Не змінює повідомлення взагалі.

scissors

Те саме, що й whitespace, за винятком того, що все, починаючи з рядка нижче (включно), обрізається, якщо повідомлення потрібно редагувати. "#" можна налаштувати за допомогою core.commentChar.

# ------------------------ >8 ------------------------
default

Те саме, що й strip, якщо повідомлення потрібно редагувати. В іншому випадку whitespace.

Стандартну поведінку можна змінити за допомогою змінної конфігурації commit.cleanup (див. git-config[1]).

-e
--edit

Дозволяє користувачеві додатково редагувати повідомлення, взяте з <файлу> за допомогою -F <файл>, командного рядка за допомогою -m <повідомлення> та з <коміту> за допомогою -C <коміту>.

--no-edit

Використовувати вибране повідомлення коміту без запуску редактора. Наприклад, git commit --amend --no-edit виправляє коміт без зміни його повідомлення.

--amend

Змінює вершину поточної гілки, створенням нового коміту. Записане дерево готується як завжди (включаючи ефект опцій -i та -o і явного визначення шляху), а повідомлення з оригінального коміту використовується як відправна точка, замість порожнього повідомлення, коли жодне інше повідомлення не вказано з командного рядка за допомогою таких опцій, як -m, -F, -c тощо. Новий коміт має тих самих батьків та автора, що й поточний (опція --reset-author може скасувати це).

Це приблизний еквівалент для:

	$ git reset --soft HEAD^
	$ ... зробіть щось ще, щоб навести лад в дереві...
	$ git commit -c ORIG_HEAD

але може бути використаний для внесення змін до коміту злиття.

Ви повинні розуміти наслідки перезапису історії, якщо ви вносите зміни до коміту, який вже був опублікований. (Див. розділ "ВІДНОВЛЕННЯ З ВИСХІДНОГО ПЕРЕБАЗУВАННЯ" в git-rebase[1].)

--no-post-rewrite

Оминути гачок post-rewrite.

-i
--include

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

-o
--only

Створює коміт, взявши оновлений вміст робочого дерева шляхів, зазначених у командному рядку, ігноруючи будь-який вміст, який був підготовлений для інших шляхів. Це режим стандартний роботи git commit, якщо в командному рядку вказані будь-які шляхи, і в цьому випадку цю опцію можна пропустити. Якщо цю опцію вказано разом з --amend, тоді шляхи вказувати не потрібно, що можна використовувати для виправлення останнього коміту без фіксації змін, які вже були підготовлені. Якщо використовується разом з --allow-empty, шляхи також не потрібні, і буде створено порожній коміт.

--pathspec-from-file=<файл>

Передайте специфікатор шляху у <file> замість аргументів командного рядка. Якщо <file> дорівнює -, тоді використовується стандартний ввід. Елементи специфікатора шляху розділяються символами LF або CR/LF. Елементи специфікатора шляху можна брати в лапки, як пояснено для змінної конфігурації core.quotePath (див. git-config[1]). Див. також --pathspec-file-nul та глобальну змінну --literal-pathspecs.

--pathspec-file-nul

Має сенс лише з --pathspec-from-file. Елементи Pathspec розділяються символом NUL, а всі інші символи (включно з символами нового рядка та лапками) сприймаються буквально.

-u[<режим>]
--untracked-files[=<режим>]

Показує файли, які не відстежуютьтся в репозиторії.

Параметр <режим> є необовʼязковим (стандартне значення all) і використовується для визначення обробки файлів, що не відстежуються в репозиторії; коли -u не використовується, стандартне значення — normal, тобто показувати файли та теки, що не відстежуються.

Можливі варіанти:

no

Не показувати невідстежувані файли

normal

Показує невідстежувані файли та теки

all

Також показує файли в невідстежуваних теках.

Усі звичайні варіанти написання логічного значення true приймаються як normal, а false як no. Стандартні значення можна змінити за допомогою змінної конфігурації status.showUntrackedFiles, описаної в git-config[1].

-v
--verbose

Показує уніфіковані відмінності (diff) між комітом HEAD та тим, що буде зафіксовано, внизу шаблону повідомлення коміту, щоб допомогти користувачеві описати коміт, нагадавши, які зміни він вніс. Зверніть увагу, що цей вивід відмінностей не має рядків, що починаються з #. Ці відмінності не будуть частиною повідомлення коміту. Дивіться змінну конфігурації commit.verbose у git-config[1].

Якщо вказано двічі, додатково показати уніфіковані відмінності між тим, що буде зафіксовано, та файлами робочого дерева, тобто не індексовані зміни у відстежуваних файлах.

-q
--quiet

Не виводить повідомлення з підсумком коміту.

--dry-run

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

--status

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

--no-status

Не додавати вивід git-status[1] до шаблону повідомлення коміту, якщо використовуєте редактор для підготовки стандартного повідомлення коміту.

-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

GPG-підпис коміту. <key-id> є необовʼязковим і стандартно використовує ідентифікатор комітера; якщо його вказано, він має бути привʼязаний до опції без пробілу. --no-gpg-sign корисний для скасування як змінної конфігурації commit.gpgSign, так і попередньої змінної --gpg-sign.

--

Не інтерпретує жодних додаткових аргументів як опції.

<pathspec>...

Коли в командному рядку вказано <специфікатор шляху>, фіксує вміст файлів, що відповідають специфікатору шляху, без запису змін, які вже були додані до індексу. Вміст цих файлів також поміщається в наступний коміт поверх того, що було поміщено в індекс раніше.

Для отримання додаткової інформації див. елемент «pathspec» у gitglossary[7].

ПРИКЛАДИ

Під час запису власної роботи вміст змінених файлів у вашому робочому дереві тимчасово зберігається в області проміжного зберігання (stage), що назвою "індексом" за допомогою git add. Файл можна повернути назад, лише в індексі, але не в робочому дереві, до стану останнього коміту за допомогою git restore --staged <файл>, що фактично скасовує git add і запобігає внесенню змін до цього файлу до наступного коміту. Після побудови стану для інкрементного коміту за допомогою цих команд, git commit (без будь-якого параметра імені шляху) використовується для запису того, що було додано в stage на поточний момент. Це найпростіша форма команди. Приклад:

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

Замість того щоб розміщувати файли після кожної окремої зміни, ви можете наказати команді git commit відстежувати зміни у файлах, вміст яких відстежується у вашому робочому дереві, та виконувати відповідні команди git add та git rm. Тобто, цей приклад робить те саме, що й попередній, якщо у вашому робочому дереві немає інших змін:

$ edit hello.c
$ rm goodbye.c
$ git commit -a

Команда git commit -a спочатку переглядає ваше робоче дерево, помічає, що ви змінили hello.c та видалили goodbye.c, та виконує необхідні git add та git rm.

Після додавання змін у багатьох файлах в stage ви можете змінити порядок запису змін, вказавши шляхи до git commit. Коли шляхи вказано, команда створює коміт, який записує лише зміни, внесені до вказаних шляхів:

$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile

Це створює коміт, який записує модифікацію в Makefile. Зміни, що були внесені до hello.c та hello.h, не включаються до результуючого коміту. Однак їхні зміни не втрачаються — вони все ще зберігаються в індексі та просто затримуються. Після наведеної вище послідовності, якщо ви це зробите:

$ git commit

цей другий коміт запише зміни до hello.c та hello.h, як і очікувалося.

Після того як злиття (ініційоване командою git merge або git pull) зупиняється через конфлікти, чисто обʼєднані шляхи вже підготовлені для фіксації, а шляхи, що конфліктували, залишаються в необʼєднаному стані. Спочатку вам потрібно перевірити, які шляхи конфліктують, за допомогою git status, а після виправлення їх вручну у вашому робочому дереві, ви підготуєте результат як завжди за допомогою git add:

$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c

Після розвʼязання конфліктів та розміщення результату в stage, git ls-files -u перестане згадувати конфліктний шлях. Коли ви закінчите, виконайте git commit, щоб остаточно записати злиття:

$ git commit

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

ІНФОРМАЦІЯ КОМІТУ

Інформація про автора та комітера береться з наступних змінних середовища, якщо вони встановлені:

  • GIT_AUTHOR_NAME

  • GIT_AUTHOR_EMAIL

  • GIT_AUTHOR_DATE

  • GIT_COMMITTER_NAME

  • GIT_COMMITTER_EMAIL

  • GIT_COMMITTER_DATE

(примітка: "<", ">" та "\n" видаляються)

Імена автора та комітера за домовленістю є певною формою особистого імені (тобто імені, за яким до вас звертаються інші люди), хоча Git не примушує та не вимагає від вас використання жодної конкретної форми. Можна використовувати довільний Unicode текст, з урахуванням обмежень, перелічених вище. Це імʼя не впливає на автентифікацію; для цього дивіться змінну credential.username у git-config[1].

Якщо (деякі з) цих змінних середовища не встановлено, інформація береться з елементів конфігурації user.name та user.email, або, якщо вони відсутні, зі змінної середовища EMAIL, або, якщо її не встановлено, з системного імені користувача та імені хосту, що використовується для вихідної пошти (береться з /etc/mailname або, якщо такого файлу немає, з повного імені хосту).

Змінні author.name та committer.name, а також відповідні їм параметри електронної пошти, перевизначають user.name та user.email, якщо вони встановлені, і самі перевизначаються змінними середовища.

Типове використання полягає в тому, щоб встановити лише змінні user.name та user.email; інші опції надаються для складніших випадків використання.

ФОРМАТИ ДАТИ

Змінні середовища GIT_AUTHOR_DATE та GIT_COMMITTER_DATE підтримують такі формати дати:

Внутрішній формат Git

Це <unix-timestamp> <time-zone-offset>, де <unix-timestamp> — це кількість секунд, що минула з епохи UNIX. <time-zone-offset> — це додатне або від’ємне зміщення від UTC. Наприклад, CET (який на 1 годину випереджає UTC) дорівнює +0100.

RFC 2822

Стандартний формат дати, як описано в RFC 2822, наприклад, Чт, 07 квітня 2005 22:13:13 +0200.

ISO 8601

Час і дата, визначені стандартом ISO 8601, наприклад, 2005-04-07T22:13:13. Парсер також приймає пробіл замість символу T. Дробові частини секунди будуть ігноруватися, наприклад, 2005-04-07T22:13:13.019 буде оброблено як 2005-04-07T22:13:13.

Note
 Крім того, частина дати приймається в таких форматах: РРРР.ММ.ДД, ММ/ДД/РРРР та ДД.ММ.РРРР.

Окрім розпізнавання всіх вищезазначених форматів дати, опція --date також спробує розібратися з іншими, більш орієнтованими на людину форматами дати, такими як відносні дати, такі як «вчора» або «минулої пʼятниці опівдні».

ОБГОВОРЕННЯ

Хоча це й не є обовʼязковим, але гарним тоном є починати опис коміту з короткого (не більше 50 символів) рядка, який стисло описує зміни за яким слідує порожній рядок, а потім більш детальний опис. Текст до першого порожнього рядка в повідомленні коміту обробляється як заголовок коміту, і цей заголовок використовується в Git в різних місцях. Наприклад, команда git-format-patch[1] перетворює коміт в email, і вона використовує заголовок в рядку Subject, а решту коміту в тілі письма.

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

  • Вміст блоб-обʼєктів — це неінтерпретовані послідовності байтів. На рівні ядра немає перетворення кодування.

  • Імена шляхів закодовано у формі нормалізації UTF-8 C. Це стосується обʼєктів дерева, індексного файлу, імен посилань, а також імен шляхів в аргументах командного рядка, змінних середовища та конфігураційних файлах (.git/config (див. git-config[1]), gitignore[5], gitattributes[5] та gitmodules[5]).

    Зверніть увагу, що Git на рівні ядра трактує шляхи просто як послідовності байтів, відмінних від NUL, немає перетворень кодування шляхів (за винятком Mac та Windows). Тому використання шляхів, відмінних від ASCII, здебільшого працюватиме навіть на платформах та файлових системах, які використовують застарілі розширені кодування ASCII. Однак репозиторії, створені на таких системах, не працюватимуть належним чином на системах на основі UTF-8 (наприклад, Linux, Mac, Windows) і навпаки. Крім того, багато інструментів на основі Git просто вважають шляхи UTF-8 і не відображатимуть інші кодування належним чином.

  • Повідомлення журналу комітів зазвичай кодуються в UTF-8, але також підтримуються інші розширені кодування ASCII. Це включає ISO-8859-x, CP125x та багато інших, але не UTF-16/32, EBCDIC та багатобайтові кодування CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx тощо).

Хоча ми рекомендуємо використовувати кодування повідомлень журналу комітів в UTF-8, як ядро, так і Git Porcelain розроблені таким чином, щоб не навʼязувати UTF-8 проєктам. Якщо всі учасники певного проєкту вважають зручнішим використовувати застарілі кодування, Git цього не забороняє. Однак, є кілька речей, які слід памʼятати.

  1. git commit та git commit-tree видають попередження, якщо повідомлення журналу комітів, надане їм, не виглядає як коректний рядок UTF-8, окрім випадків, коли ви явно вкажете, що ваш проєкт використовує застаріле кодування. Це можна зробити, додавши i18n.commitEncoding у файл .git/config, ось так:

    [i18n]
	commitEncoding = ISO-8859-1

    Обʼєкти комітів, створені з використанням вищевказаного налаштування, записують значення i18n.commitEncoding у свій заголовок encoding. Це зроблено для того, щоб допомогти іншим користувачам, які переглядатимуть їх пізніше. Відсутність цього заголовка означає, що повідомлення журналу комітів закодоване в UTF-8.

  2. git log, git show, git blame та інші команди переглядають заголовок encoding обʼєкта коміту та намагаються перекодувати повідомлення журналу в UTF-8, якщо не вказано інше. Ви можете вказати потрібне кодування виводу за допомогою i18n.logOutputEncoding у файлі .git/config, ось так:

    [i18n]
	logOutputEncoding = ISO-8859-1

    Якщо у вас немає цієї змінної конфігурації, замість неї використовується значення i18n.commitEncoding.

Зверніть увагу, що ми навмисно вирішили не перекодувати повідомлення журналу комітів, коли коміт робиться для примусового використання UTF-8 на рівні обʼєкта коміту, оскільки перекодування в UTF-8 не обовʼязково є оборотною операцією.

ЗМІННІ СЕРЕДОВИЩА ТА КОНФІГУРАЦІЇ

Редактор, який використовується для редагування журналу повідомлень комітів, буде вибрано з таких змінних середовища: GIT_EDITOR, змінна конфігурації core.editor, змінна середовища VISUAL або змінна середовища EDITOR (у такому порядку). Детальніше див. git-var[1].

Все, що знаходиться вище цього рядка в цьому розділі, не включено до документації git-config[1]. Наступний вміст такий самий, як і той, що знаходиться там:

commit.cleanup

Це налаштування замінює стандартне значення параметра --cleanup у команді git commit. Зміна стандартного значення може бути корисною, якщо ви завжди хочете зберігати у своєму повідомленні журналу рядки, що починаються з символу коментаря (core.commentChar, типове значення #). У цьому випадку вам слід виконати команду git config commit.cleanup whitespace (зверніть увагу, що в такому разі вам доведеться самостійно видалити рядки довідки, що починаються з символу коментаря, у шаблоні журналу комітів).

commit.gpgSign

Булева змінна, що визначає, чи слід підписувати всі коміти за допомогою GPG. Використання цієї опції під час виконання таких операцій, як rebase, може призвести до підписання великої кількості комітів. Щоб уникнути багаторазового введення пароля GPG, доцільно скористатися агентом.

commit.status

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

commit.template

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

commit.verbose

Булеве значення або ціле число для визначення рівня деталізації команди git commit.

ГАЧКИ

Ця команда може виконувати гачки commit-msg, prepare-commit-msg, pre-commit, post-commit та post-rewrite. Див. githooks[5] для отримання додаткової інформації.

ФАЙЛИ

$GIT_DIR/COMMIT_EDITMSG

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

ДИВ. ТАКОЖ

git-add[1], git-rm[1], git-mv[1], git-merge[1], git-commit-tree[1]

GIT

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