українська мова ▾ Topics ▾ Latest version ▾ git-commit last updated in 2.51.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

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

-p
--patch

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

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

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

--inter-hunk-context=<n>

Показує контекст між різницями (diff hanks), до вказаної <кількості> рядків, таким чином об’єднуючи ханки, що знаходяться близько один до одного. За замовчуванням використовується значення 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, або під час коміту після конфліктного вибору, оголошує, що авторство результуючого коміту тепер належить коміттеру. Це також поновлює позначку часу автора.

--short

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

--branch

Відображати відділення та інформацію про відстеження навіть у скороченому форматі.

--porcelain

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

--long

Під час пробного запуску, виводьте результат у довгому форматі. Має на увазі --dry-run.

-z
--null

Під час виведення статусу short або porcelain, виведіть дослівно назву файлу та завершуйте записи символами 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

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

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

--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
--[no-]verify

Обійти хуки pre-commit та commit-msg. Див. також githooks[5].

--allow-empty

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

--allow-empty-message

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

--cleanup=<режим>

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

strip

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

whitespace

Те саме, що й strip, але #commentary не видаляється.

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=<файл>

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

--pathspec-file-nul

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

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

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

Параметр <mode> є необов’язковим (за замовчуванням має значення 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-sign. <key-id> є необов’язковим і за замовчуванням використовує ідентифікатор комітера; якщо його вказано, він має бути прив’язаний до опції без пробілу. --no-gpg-sign корисний для скасування як змінної конфігурації commit.gpgSign, так і попередньої змінної --gpg-sign.

--

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

<pathspec>...

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

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

ПРИКЛАДИ

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

$ 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.

Після розміщення змін у багатьох файлах ви можете змінити порядок запису змін, вказавши шляхи до 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

Після вирішення конфліктів та розміщення результату, 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] перетворює коміт на електронну пошту та використовує заголовок у рядку теми, а решту коміту — у тілі листа.

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]. Наступний вміст такий самий, як і той, що знаходиться там:

Warning

Missing uk/config/commit.adoc

See original version for this content.

ГАЧКИ

Ця команда може виконувати перехоплювачі 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]