Git
Русский ▾ Topics ▾ Latest version ▾ git-commit last updated in 2.46.1

НАЗВАНИЕ

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

ОБЗОР

git commit [-a | --interactive | --patch] [-s] [-v] [-u<режим>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <коммит> | --fixup [(amend|reword):]<коммит>]
	   [-F <файл> | -m <сообщение>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<автор>]
	   [--date=<дата>] [--cleanup=<режим>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<файл> [--pathspec-file-nul]]
	   [(--trailer <лексема>[(=|:)<значение>])…​] [-S[<id-ключа>]]
	   [--] [<спецификатор-пути>…​]

ОПИСАНИЕ

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

Содержание, которое должно быть зафиксировано, может быть указано несколькими способами:

  1. с помощью git-add[1] для пошагового добавления ("add") изменений в индекс, до запуска команды commit (Примечание: даже изменённые файлы должны быть «добавлены»);

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

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

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

  5. с помощью ключей --interactive или --patch команды commit, чтобы принимать решение по каждому отдельному файлу или блоку кода, по одному за другим, какие из них должны быть частью коммита (в дополнение к тому, что уже содержится в индексе), прежде чем завершить операцию. См. раздел «Интерактивный режим» git-add[1], чтобы научиться работать в этом режиме.

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

Если вы сделаете коммит и сразу после этого заметите какую-либо ошибку, то изменения можно будет откатить с помощью git reset.

ПАРАМЕТРЫ

-a
--all

Даёт указание команде автоматически индексировать файлы, которые были изменены и удалены, но новые файлы, о которых вы ещё ничего не говорили Git не будут затронуты.

-p
--patch

Использовать интерактивный интерфейс выбора изменений, чтобы отобрать, какие изменения фиксировать. См. git-add[1].

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

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

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

Как и -C, но с -c будет запущен редактор, так что пользователь может дополнительно отредактировать сообщение коммита.

--fixup=[(amend|reword):]<коммит>

Создаёт новый коммит, который «подправляет» уже существующий <коммит>, при совместном использовании с git rebase» --autosquash. Просто --fixup=<коммит> создаёт "fixup!"-коммит, что изменит содержимое <коммита>, но не будет трогать его сообщение. --fixup=amend:<коммит> аналогичен, но создаёт "amend!"-коммит, который также заменяет сообщение <коммита> на сообщение "amend!"-коммита. --fixup=reword:<коммит> также создаёт "amend!"-коммит, но который заменяет только сообщение <коммита> на собственное, но не вносит никаких изменений в содержимое самого <коммита>.

У коммит, созданный простым --fixup=<коммит>, в качестве заголовка (первой строки коммита) используется строка, состоящая из "fixup!", за которым следует строка темы <коммита>, которую git rebase --autosquash обрабатывает специальным образом. С помощью параметра -m можно добавить какое-либо сообщение к создаваемому коммиту, но этот дополнительный комментарий будет отброшен, как только "fixup!"-коммит будет объединён с <коммитом> при выполнении git rebase --autosquash.

Коммит, созданный --fixup=amend:<коммит>, аналогичен, но в начале его заголовка добавляется "amend!". Сообщение <коммита> копируется в сообщение "amend!"-коммита и открывается редактор, в котором это сообщение можно изменить. Когда git rebase --autosquash объединяет "amend!"-коммит с <коммитом>, сообщение <коммита> заменяется отредактированным сообщением "amend!"-коммита. Пустое сообщение в "amend!"-коммите является ошибкой, если только не указан параметр --allow-empty-message.

--fixup=reword:<коммит> является короткой записью для --fixup=amend:<коммит> --only. Он создаёт "amend!"-коммит, содержащий только сообщение коммита (игнорирую любые изменения, внесённые в индекс). Когда он будет объединён с другим коммитом git rebase --autosquash, он заменит сообщение <коммита>, но не произведёт никаких других изменений.

При выполнении git rebase --autosquash, ни "fixup!", ни "amend!" не изменяют информацию об авторстве <коммита>. См. подробности в git-rebase[1].

--squash=<коммит>

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

Переопределить автора коммита. Чтобы задать автора явно, используйте стандартный формат: А В Тор <author@example.com>. В противном случае значение <автор> считается шаблоном, который используется для поиска какого-либо существующего коммита этого автора (т.е. rev-list --all -i --author=<автор>); информация об авторе затем будет скопирован с первого такого найденного коммита.

--date=<дата>

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

-m <сообщение>
--message=<сообщение>

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

Параметр -m является взаимоисключающим с -c, -C и -F.

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

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

-s
--signoff
--no-signoff

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

С помощью параметра --no-signoff можно отменить параметр --signoff, указанный раннее в командной строке.

--trailer <лексема>[(=|:)<значение>]

Задаёт пару (<лексема>,<значение>), которая должна быть добавлена в качестве завершителя. (например, git commit --trailer "Signed-off-by:К О Миттер <committer@example.com>" --trailer "Helped-by:К О Миттер <committer@example.com>" добавит завершители "Signed-off-by" и "Helped-by" к сообщению коммита). Определить, какое должно быть поведение в случае, если завершитель применяется несколько раз или в каком порядке они должны идти, а также другие детали можно с помощью семейства конфигурационных переменных trailer.* (См. git-interpret-trailers[1]).

-n
--[no-]verify

По умолчанию при коммите запускаются перехватчики вызовов pre-commit и commit-msg. Когда указаны параметры --no-verify или -n, эти перехватчики не будут запущены. См. также githooks[5].

--allow-empty

Обычно запись коммита, с точно таким же деревом каталогов, как и у его (единственного) родителя, является ошибкой, и данная команда не даст вам создать такой коммит. Данный параметр позволяет обойти это ограничение; в основном он используется в сценариях, взаимодействующих c другими СКВ.

--allow-empty-message

Подобно --allow-empty, этот параметр в основном используется в сценариях, взаимодействующих c другими СКВ. Он позволяет вам создать коммит с пустым сообщением без возни с внутренними интерфейсами Git такими, как git-commit-tree[1].

--cleanup=<режим>

Этот параметр определяет, каким образом предоставленное сообщение коммита должно быть очищено перед тем, как собственно произвести коммит. <режим> может быть одним из: strip, whitespace, verbatim, scissors или default.

strip

Удалять начальные и конечные пустые строки, лишние конечные пробелы, комментарии, а также лишние последовательные пустые строки.

whitespace

То же, что и strip, но #комментарии не удаляются.

verbatim

Не производить ни какие изменения сообщения коммита.

scissors

То же, что и whitespace, но, если сообщение было получено из редактора, то всё, что находится ниже следующей строки (включая саму строку), будет обрезано. Символ комментария «#» можно изменить в переменной конфигурации core.commentChar.

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

Если сообщение было получено из редактора, то то же, что и strip. Иначе — whitespace.

Значение по умолчанию может быть изменено в переменной конфигурации commit.cleanup (cм. 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

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

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

--no-post-rewrite

Пропустить перехватчик post-rewrite.

-i
--include

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

-o
--only

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

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

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

--pathspec-file-nul

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

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

Отображать неотслеживаемые файлы.

Аргумент <режим> является необязательным (по умолчанию: 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[<id-ключа>]
--gpg-sign[=<id-ключа>]
--no-gpg-sign

Подписывать коммиты с помощью GPG. Аргумент id-ключа необязателен, и если не указан, в качестве значения по умолчанию будет использоваться личное имя коммиттера; если аргумент указан, он должен следовать сразу после параметра, без пробела. Параметр --no-gpg-sign полезен, если нужно отменить переменную конфигурации commit.gpgSign или параметр --gpg-sign, заданный ранее.

--

Не рассматривать остальные аргументы командной строки в качестве параметров.

<спецификатор-пути>…

Когда в командной строке указан спецификатор пути, в коммит добавляется содержимое файлов, соответствующих этому спецификатору, другие изменения, добавленные в индекс не будут добавлены в коммит. Изменения, которые уже находятся в индексе, но небыли зафиксированы останутся в индексе и могут быть зафиксированы следующим коммитом.

Более подробно описание см. в параграфе спецификатор пути (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 add за вас. То есть, этот пример делает то же самое, что и предыдущий пример, если в вашем рабочем каталоге не было ни каких других изменений:

$ 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 (00:00:00 UTC 1 января 1970 года). А <time-zone-offset> является положительным или отрицательным смещением относительно UTC. Например, для CET (центральноевропейское время которое на 1 час опережает UTC) значение будет +0100.

RFC 2822

Стандартный формат даты, описанный RFC 2822, например, Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Время и дата, согласно стандарту ISO 8601, например, 2005-04-07T22:13:13'. Принимается также пробел вместо `Т. Дробные доли секунды будут отброшены, например ‘2005-04-07T22:13:13.019’ будет восприниматься как ‘2005-04-07T22:13:13’.

Note
 Кроме того, часть представляющая дату принимается в следующих форматах: ГГГГ.ММ.ДД, ММ/ДД/ГГГГ и ДД.ММ.ГГГГ.

В дополнение к форматам даты перечисленным выше, параметр --date также попытается распознать и другие, более ориентированные на человека, форматы дат такие, как относительные даты, вроде "yesterday" («вчера») или "last Friday at noon" («в прошлую пятницу в полдень»).

ОБСУЖДЕНИЕ

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

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

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

  • Пути кодируются в UTF-8 в форме нормализации C. Это относится к объектам-деревьям, файлу индекса, именам ссылок, а также к путям в аргументах командной строки, переменных среды и файлах конфигурации (.git/config (см. git-config[1]), gitignore[5], gitattributes[5] и gitmodules[5]).

    Обратите внимание, что Git на базовом уровне рассматривает имена путей просто как последовательности ненулевых байтов, ни каких перекодировок путей не происходит (за исключением 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, и высокоуровневые пользовательские программны разработаны так, чтобы не принуждать к обязательному использованию 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 ru/config/commit.txt

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]

scroll-to-top