Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.49.1 → 2.54.0 no changes
-
2.49.0
2025-03-14
- 2.45.1 → 2.48.2 no changes
-
2.45.0
2024-04-29
- 2.43.1 → 2.44.4 no changes
-
2.43.0
2023-11-20
- 2.35.1 → 2.42.4 no changes
-
2.35.0
2022-01-24
- 2.31.1 → 2.34.8 no changes
-
2.31.0
2021-03-15
- 2.27.1 → 2.30.9 no changes
-
2.27.0
2020-06-01
- 2.25.2 → 2.26.3 no changes
- 2.25.1 no changes
- 2.22.1 → 2.25.0 no changes
-
2.22.0
2019-06-07
- 2.14.6 → 2.21.4 no changes
-
2.13.7
2018-05-22
- 2.12.5 no changes
-
2.11.4
2017-09-22
- 2.10.5 no changes
-
2.9.5
2017-07-30
- 2.7.6 → 2.8.6 no changes
-
2.6.7
2017-05-05
- 2.5.6 no changes
-
2.4.12
2017-05-05
- 2.1.4 → 2.3.10 no changes
-
2.0.5
2014-12-17
ОБЗОР
git commit-tree <дерево> [(-p <родитель>)…] git commit-tree [(-p <родитель>)…] [-S[<id-ключа>]] [(-m <сообщение>)…] [(-F <файл>)…] <дерево>
ОПИСАНИЕ
Обычно это не то, что конечный пользователь хочет запускать напрямую. Вместо этого см. git-commit[1].
Создаёт новый объект коммита на основе предоставленного объекта дерева и выводит id нового объекта коммита в stdout. Сообщение журнала читается из стандартного ввода, если не указаны параметры -m или -F.
Параметры -m и -F могут быть указаны любое количество раз, в любом порядке. Сообщение журнала коммита будет составлено в том порядке, в котором указаны параметры.
Объект коммита может иметь любое количество родителей. Ровно с одним родителем это обычный коммит. Наличие более одного родителя делает коммит слиянием нескольких линий истории. Начальные (корневые) коммиты не имеют родителей.
В то время как дерево представляет определённое состояние каталога рабочего каталога, коммит представляет это состояние во "времени" и объясняет, как туда попасть.
Обычно коммит идентифицирует новое состояние "HEAD", и хотя Git не заботится о том, где вы сохраняете заметку об этом состоянии, на практике мы склонны просто записывать результат в файл, на который указывает .git/HEAD, чтобы мы всегда могли видеть, каким было последнее зафиксированное состояние.
ПАРАМЕТРЫ
- <tree>
-
Существующий объект дерева.
- -p <родитель>
-
Каждый
-pуказывает id родительского объекта коммита. - -m <сообщение>
-
Абзац в сообщении журнала коммита. Это может быть указано более одного раза, и каждое <сообщение> становится отдельным абзацем.
- -F <файл>
-
Прочитать сообщение журнала коммита из указанного файла. Используйте
-для чтения из стандартного ввода. Это может быть указано более одного раза, и содержимое каждого файла становится отдельным абзацем. - -S[<id-ключа>]
- --gpg-sign[=<id-ключа>]
- --no-gpg-sign
-
Подписывать коммиты GPG. Аргумент
keyidявляется необязательным и по умолчанию равен идентификатору коммиттера; если указан, он должен примыкать к параметру без пробела.--no-gpg-signполезен для отмены параметра--gpg-sign, указанного ранее в командной строке.
Информация о коммите
Коммит инкапсулирует:
-
все id родительских объектов
-
имя автора, адрес электронной почты и дата
-
имя коммиттера, адрес электронной почты и время коммита.
Комментарий к коммиту читается из stdin. Если запись журнала изменений не предоставлена через перенаправление "<", git commit-tree будет просто ждать, пока она не будет введена и не завершена с помощью ^D.
ФОРМАТЫ ДАТЫ
Переменные среды 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,07Apr200522:13:13+0200. - ISO 8601
-
Время и дата, согласно стандарту ISO 8601, например, 2005-04-07T22:13:13'. Принимается также пробел вместо `Т. Дробные доли секунды будут отброшены, например ‘2005-04-07T22:13:13.019’ будет восприниматься как ‘2005-04-07T22:13:13’.
NoteКроме того, часть представляющая дату принимается в следующих форматах: ГГГГ.ММ.ДД, ММ/ДД/ГГГГ и ДД.ММ.ГГГГ.
Обсуждение
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 не запрещает это. Однако есть несколько моментов, которые стоит иметь в виду.
-
gitcommitиgitcommit-treeбудут выдавать предупреждение, если переданное ему сообщение коммита не похоже на корректную строку UTF-8, если только вы явно не объявили, что ваш проект использует устаревшую кодировку. Это можно сделать, добавив переменную конфигурацииi18n.commitEncodingв файл.git/config, например:[i18n] commitEncoding = ISO-8859-1
Объекты-коммиты, которые будут созданные пока включена приведённая выше настройка, будут записывать значение
i18n.commitEncodingв своём заголовкеencoding. Это поможет другим людям, которые будут просматривать их позже. Отсутствие этого заголовка означает, что сообщение коммита использует кодировку в UTF-8. -
gitlog,gitshow,gitblameи другие подобные команды смотрят на заголовокencodingобъекта-коммита, и пытаются перекодировать сообщение журнала в UTF-8, если не указано иное. Вы можете указать нужную кодировку вывода с помощьюi18n.logOutputEncodingв файле.git/config, например:[i18n] logOutputEncoding = ISO-8859-1
Если эта переменная конфигурации у вас не установлена, то вместо ней используется значение
i18n.commitEncoding.
Заметьте, что мы сознательно решили не перекодировать сообщения коммитов прямо во время создания коммита (т.е. не принуждать к использованию UTF-8 на уровне объектов-коммитов), потому что перекодировка в UTF-8 не обязательно является обратимой операцией.
GIT
Является частью пакета git[1]