Spec-Zone.ru › Git

git-commit

Название

git-commit — запись изменений в репозиторий

Краткое описание

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
           [--dry-run] <commit>_ | --fixup [(amend|reword):"><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, чтобы автоматически «добавить» изменения во всех известных файлах (то есть во всех файлах, уже перечисленных в индексе) и автоматически выполнить «rm» для файлов в индексе, удалённых из рабочего дерева, а затем выполнить собственно коммит;

  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, если переменная конфигурации не задана. (-U без <n> принимается без уведомления как синоним -p в силу исторической случайности).

--inter-hunk-context=<n>

Показывать контекст между фрагментами различий, не более указанного <number> строк, тем самым объединяя близко расположенные фрагменты. По умолчанию используется diff.interHunkContext или 0, если параметр конфигурации не задан.

-C <commit>
--reuse-message=<commit>

Взять существующий объект <commit> и повторно использовать сообщение журнала и информацию об авторстве (включая временную метку) при создании коммита.

-c <commit>
--reedit-message=<commit>

Как -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=<commit>

Создать сообщение коммита для использования с 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

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

--long

При пробном запуске выводить данные в подробном формате. Это формат вывода git-status[1] по умолчанию. Подразумевает --dry-run.

-z
--null

При отображении вывода git-status[1] в формате short или porcelain выводить имена файлов без изменений и завершать записи символом NUL вместо LF. Если формат не указан, подразумевает формат вывода --porcelain. Без параметра -z имена файлов с «необычными» символами заключаются в кавычки, как описано для переменной конфигурации core.quotePath (см. git-config[1]).

-F <file>
--file=<file>

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

--author=<author>

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

--date=<date>

Переопределить дату автора, используемую в коммите.

-m <msg>
--message=<msg>

Использовать <msg> как сообщение коммита. Если указано несколько параметров -m, их значения объединяются в отдельные абзацы.

Параметр -m несовместим с параметрами -c, -C и -F.

-t <file>
--template=<file>

При редактировании сообщения коммита открыть редактор с содержимым <file>. Переменная конфигурации commit.template часто используется, чтобы неявно передавать эту опцию команде. Этот механизм могут использовать проекты, желающие дать участникам подсказки о том, что и в каком порядке писать в сообщении. Если пользователь выйдет из редактора, не отредактировав сообщение, создание коммита будет прервано. Это не действует, если сообщение задано другим способом, например с помощью параметров -m или -F.

-s
--signoff
--no-signoff

Добавить в конец сообщения журнала коммита завершающую строку Signed-off-by от имени коммиттера. Значение signoff зависит от проекта, в который вы отправляете изменения. Например, это может подтверждать, что коммиттер имеет право предоставить работу на условиях лицензии проекта или согласен с некоторым представлением об участниках, например с Сертификатом происхождения разработчика (Developer Certificate of Origin). (Информацию о варианте, используемом проектами ядра Linux и Git, см. на странице https://developercertificate.org.) Чтобы понять, как signoff используется в проекте, ознакомьтесь с его документацией или обратитесь к его руководству.

Параметр --no-signoff можно использовать, чтобы отменить ранее указанный в командной строке параметр --signoff.

Git не имеет и не будет иметь переменной конфигурации для включения по умолчанию параметра командной строки --signoff; подробности см. в пункте commit.signoff файла gitfaq[7].

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

Указать пару (<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

Создать коммит с пустым сообщением без использования низкоуровневых команд, таких как git-commit-tree[1]. Как и --allow-empty, эта команда предназначена главным образом для использования скриптами интерфейсов к внешним SCM.

--cleanup=<mode>

Определить, как следует очистить перед фиксацией предоставленное сообщение коммита. <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

Позволить пользователю дополнительно отредактировать сообщение, полученное из <file> с помощью -F <file>, из командной строки с помощью -m <message> или из <commit> с помощью -C <commit>.

--no-edit

Использовать выбранное сообщение коммита, не запуская редактор. Например, git commit --amend --no-edit изменяет коммит, не меняя его сообщение.

--amend

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

Это примерно эквивалентно:

        $ git reset --soft HEAD^
        $ ... do something else to come up with the right tree ...
        $ git commit -c ORIG_HEAD

но этот параметр также можно использовать для изменения коммита слияния.

Если вы изменяете уже опубликованный коммит, следует понимать последствия переписывания истории. (См. раздел «ВОССТАНОВЛЕНИЕ ПОСЛЕ REBASE ОТНОСИТЕЛЬНО ВЕРХНЕГО РЕПОЗИТОРИЯ» в git-rebase[1].)

--no-post-rewrite

Обойти хук post-rewrite.

-i
--include

Перед созданием коммита из уже добавленного в индекс содержимого также добавить содержимое указанных в командной строке путей. Обычно это не то, что вам нужно, если только вы не завершаете слияние с конфликтами.

-o
--only

Создать коммит, взяв обновлённое содержимое рабочего дерева для указанных в командной строке путей и проигнорировав содержимое, добавленное в индекс для других путей. Это режим работы git commit по умолчанию, если в командной строке указаны пути; в этом случае этот параметр можно опустить. Если этот параметр указан вместе с --amend, указывать пути не требуется; это можно использовать, чтобы изменить последний коммит, не включая уже добавленные в индекс изменения. При использовании вместе с --allow-empty пути также не требуются, и будет создан пустой коммит.

--pathspec-from-file=<file>

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

--pathspec-file-nul

Имеет смысл только вместе с --pathspec-from-file. Элементы спецификации путей разделяются символом NUL, а все остальные символы воспринимаются буквально (включая символы новой строки и кавычки).

-u[<mode>]
--untracked-files[=<mode>]

Показывать неотслеживаемые файлы.

Параметр <mode> необязателен (по умолчанию используется all) и задаёт способ обработки неотслеживаемых файлов; если -u не используется, по умолчанию применяется normal, то есть показываются неотслеживаемые файлы и каталоги.

Возможные значения:

no

Не показывать неотслеживаемые файлы

normal

Показывать неотслеживаемые файлы и каталоги

all

Также показывать отдельные файлы в неотслеживаемых каталогах.

Все обычные варианты написания логического значения true воспринимаются как normal, а false — как no. Значение по умолчанию можно изменить с помощью переменной конфигурации status.showUntrackedFiles, описанной в git-config[1].

-v
--verbose

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

Дополнительные сведения см. в статье pathspec в gitglossary[7].

Примеры

При записи собственных изменений содержимое изменённых файлов в рабочем дереве временно сохраняется в области подготовленных изменений, называемой «индексом», с помощью git add. Файл можно вернуть к состоянию последнего коммита только в индексе, но не в рабочем дереве, с помощью git restore --staged <file>, что фактически отменяет действие 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 не навязывает и не требует какого-либо конкретного формата. Можно использовать любые символы Юникода с учётом перечисленных выше ограничений. Это имя не влияет на аутентификацию; сведения об этом см. в описании переменной 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.

Безопаснее предварять <unix-timestamp> значением @ (например, @0 +0000), чтобы принудительно интерпретировать его как необработанную временную метку. Это необходимо для значений меньше 100 000 000 (содержащих менее 9 цифр), чтобы избежать путаницы с другими форматами дат, например YYYYMMDD.

RFC 2822

Стандартный формат даты, описанный в RFC 2822, например Thu, 07 Apr 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.

Примечание
 Кроме того, часть с датой принимается в следующих форматах: YYYY.MM.DD, MM/DD/YYYY и DD.MM.YYYY.

Помимо распознавания всех перечисленных выше форматов дат, параметр --date также пытается интерпретировать другие, более понятные человеку форматы дат, например относительные даты «вчера» или «в прошлую пятницу в полдень».

Обсуждение

Хотя это и не обязательно, рекомендуется начинать сообщение коммита с одной короткой строки (не более 50 символов), кратко описывающей изменения, затем оставлять пустую строку и добавлять более подробное описание. Текст до первой пустой строки в сообщении коммита считается заголовком коммита; этот заголовок используется во всём Git. Например, git-format-patch[1] преобразует коммит в электронное письмо, помещая заголовок в строку темы, а остальную часть коммита — в тело письма.

Git в некоторой степени не зависит от кодировки символов.

  • Содержимое объектов blob — это последовательности байтов без интерпретации. На базовом уровне преобразование кодировки не выполняется.

  • Имена путей кодируются в UTF-8 в нормализованной форме C. Это относится к объектам tree, файлу индекса, именам ссылок, а также к именам путей в аргументах командной строки, переменных окружения и файлах конфигурации (.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 и многие другие, но not UTF-16/32, EBCDIC и многобайтовые кодировки CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx и т. д.).

Хотя мы рекомендуем кодировать сообщения в журнале коммитов в UTF-8, и базовая часть Git, и 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. Использование этого параметра при таких операциях, как перебазирование, может привести к подписанию большого количества коммитов. Чтобы не вводить парольную фразу 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]

commit

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-commit

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API