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.51.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 <tree> [(-p <parent>)…] git commit-tree [(-p <parent>)…] [-S[<keyid>]] [(-m <message>)…] [(-F <file>)…] <tree>
ОПИС
Зазвичай кінцевий користувач не хоче запускати це безпосередньо. Натомість дивіться git-commit[1].
Створює новий об’єкт коміту на основі наданого об’єкта дерева та виводить новий ідентифікатор об’єкта коміту на стандартний вивід. Повідомлення журналу зчитується зі стандартного вводу, якщо не задано опції -m
або -F
.
Опції -m
та -F
можна вводити будь-яку кількість разів у будь-якому порядку. Повідомлення журналу комітів буде складено в порядку вказівки опцій.
Об’єкт коміту може мати будь-яку кількість батьків. Якщо батьківський елемент рівно один, це звичайний коміт. Наявність кількох батьківських елементів робить коміт злиттям кількох рядків історії. Початкові (кореневі) коміти не мають батьківських елементів.
Хоча дерево представляє певний стан робочого каталогу, коміт представляє цей стан у "часі" та пояснює, як туди потрапити.
Зазвичай коміт визначає новий стан "HEAD", і хоча Git не хвилює, де ви зберігаєте примітку про цей стан, на практиці ми схильні просто записувати результат у файл, на який вказує .git/HEAD
, щоб ми завжди могли бачити, яким був останній закомітований стан.
ОПЦІЇ
- <tree>
-
Існуючий об’єкт дерева.
- -p <parent>
-
Кожен
-p
вказує ідентифікатор батьківського об’єкта коміту. - -m <message>
-
Абзац у повідомленні журналу комітів. Його можна вказати більше одного разу, і кожне <повідомлення> стає окремим абзацом.
- -F <file>
-
Зчитати повідомлення журналу комітів з заданого файлу. Використовуйте
-
для читання зі стандартного вводу. Це можна вказати більше одного разу, і вміст кожного файлу стає окремим абзацом. - -S[<keyid>]
- --gpg-sign[=<keyid>]
- --no-gpg-sign
-
Коміти з підписом GPG. Аргумент
keyid
є необов’язковим і за замовчуванням використовує ідентифікатор комітера; якщо його вказано, він має бути прив’язаний до опції без пробілу.--no-gpg-sign
корисний для скасування опції--gpg-sign
, заданої раніше в командному рядку.
Інформація про коміти
Коміт інкапсулює:
-
всі ідентифікатори батьківських об’єктів
-
ім’я автора, електронна адреса та дата
-
ім’я та електронна адреса комітера, а також час коміту.
Коментар до коміту зчитується зі stdin. Якщо запис журналу змін не надано через перенаправлення "<", git commit-tree просто чекатиме на його введення та завершиться символом ^D.
ФОРМАТИ ДАТИ
Змінні середовища 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Крім того, частина дати приймається в таких форматах: РРРР.ММ.ДД, ММ/ДД/РРРР та ДД.ММ.РРРР.
Обговорення
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 цього не забороняє. Однак, є кілька речей, які слід пам’ятати.
-
git
commit
таgit
commit-tree
видають попередження, якщо повідомлення журналу комітів, надане їм, не виглядає як коректний рядок UTF-8, окрім випадків, коли ви явно вкажете, що ваш проект використовує застаріле кодування. Це можна зробити, додавшиi18n.commitEncoding
у файл.git/config
, ось так:[i18n] commitEncoding = ISO-8859-1
Об’єкти комітів, створені з використанням вищевказаного налаштування, записують значення
i18n.commitEncoding
у свій заголовокencoding
. Це зроблено для того, щоб допомогти іншим користувачам, які переглядатимуть їх пізніше. Відсутність цього заголовка означає, що повідомлення журналу комітів закодоване в UTF-8. -
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
Частина набору git[1]