Setup and Config

• git
• config
• help
• bugreport
• Credential helpers

Getting and Creating Projects

• init
• clone

Basic Snapshotting

• add
• status
• diff
• commit
• notes
• restore
• reset
• rm
• mv

Branching and Merging

• branch
• checkout
• switch
• merge
• mergetool
• log
• stash
• tag
• worktree

Sharing and Updating Projects

• fetch
• pull
• push
• remote
• submodule

Inspection and Comparison

• show
• log
• diff
• difftool
• range-diff
• shortlog
• describe

Patching

• apply
• cherry-pick
• diff
• rebase
• revert

Debugging

• bisect
• blame
• grep

Email

• am
• apply
• imap-send
• format-patch
• send-email
• request-pull

External Systems

• svn
• fast-import

Server Admin

• daemon
• update-server-info

Guides

• gitattributes
• Command-line interface conventions
• Everyday Git
• Frequently Asked Questions (FAQ)
• Glossary
• Hooks
• gitignore
• gitmodules
• Revisions
• Submodules
• Tutorial
• Workflows
• All guides...

Administration

• clean
• gc
• fsck
• reflog
• filter-branch
• instaweb
• archive
• bundle

Plumbing Commands

• cat-file
• check-ignore
• checkout-index
• commit-tree
• count-objects
• diff-index
• for-each-ref
• hash-object
• ls-files
• ls-tree
• merge-base
• read-tree
• rev-list
• rev-parse
• show-ref
• symbolic-ref
• update-index
• update-ref
• verify-pack
• write-tree

git-commit-tree - Створіть новий об’єкт коміту

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月07日T22:13:13. Парсер також приймає пробіл замість символу T. Дробові частини секунди будуть ігноруватися, наприклад, 2005年04月07日T22:13:13.019 буде оброблено як 2005年04月07日T22: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 цього не забороняє. Однак, є кілька речей, які слід пам’ятати.

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 не обов’язково є оборотною операцією.

/etc/mailname

git-write-tree[1] git-commit[1]

Частина набору git[1]