українська мова ▾ Topics ▾ Latest version ▾ git-merge-tree last updated in 2.50.0

НАЗВА

git-merge-tree - Виконайте злиття без торкання індексу або робочого дерева

СИНОПСИС

git merge-tree [--write-tree] [<options>] <branch1> <branch2>
git merge-tree [--trivial-merge] <base-tree> <branch1> <branch2> (deprecated)

ОПИС

Ця команда має сучасний режим --write-tree та застарілий режим --trivial-merge. За винятком розділу ЗАСТАРІЛИЙ ОПИС в кінці, решта цієї документації описує сучасний режим --write-tree.

Виконує злиття, але не створює жодних нових комітів та не читає та не записує ні з робочого дерева, ні з індексу.

Виконане злиття використовуватиме ті ж функції, що й "справжній" git-merge[1], зокрема:

  • тристороннє об’єднання контенту окремих файлів

  • виявлення перейменування

  • належна обробка конфліктів каталогів/файлів

  • рекурсивна консолідація предків (тобто, коли є більше однієї бази злиття, створення віртуальної бази злиття шляхом об’єднання баз злиття)

  • etc.

Після завершення злиття створюється новий об’єкт дерева верхнього рівня. Див. OUTPUT нижче для отримання детальної інформації.

ОПЦІЇ

--stdin

Читайте коміти для злиття зі стандартного вводу, а не з командного рядка. Дивіться ФОРМАТ ВВОДУ нижче для отримання додаткової інформації. Має на увазі -z.

-z

Не беріть імена файлів у лапки в розділі <Інформація про конфліктуючий файл> та завершуйте кожне ім’я файлу символом NUL, а не символом нового рядка. Також починайте розділ повідомлень із символу NUL, а не символом нового рядка. Див. OUTPUT нижче для отримання додаткової інформації.

--name-only

У розділі «Інформація про конфліктні файли», замість того, щоб записувати список кортежів (режим, oid, стадія, шлях) для виведення для конфліктуючих файлів, просто надайте список імен файлів з конфліктами (і не перераховуйте імена файлів кілька разів, якщо вони мають кілька конфліктуючих стадій).

--[no-]messages

Записуйте будь-які інформаційні повідомлення, такі як "Автоматичне злиття <шлях>" або сповіщення про КОНФЛІКТИ, в кінець стандартного виводу. Якщо не вказано, за замовчуванням ці повідомлення включатимуться, якщо є конфлікти злиття, та пропускатимуться в іншому випадку.

--quiet

Вимкнути весь вивід програми. Корисно, коли вас цікавить лише статус завершення. Дозволяє merge-tree завершувати роботу раніше, якщо виявлено конфлікт, та уникати запису більшості об’єктів, створених злиттями.

--allow-unrelated-histories

merge-tree за замовчуванням виведе помилку, якщо дві вказані гілки не мають спільної історії. Цей прапорець можна встановити, щоб скасувати цю перевірку та все одно продовжити злиття.

--merge-base=<деревоподібний>

Замість пошуку баз злиття для <branch1> та <branch2>, вкажіть базу злиття для самого злиття, а вказівка кількох баз наразі не підтримується. Цей параметр несумісний з --stdin.

Оскільки база злиття надається безпосередньо, <branch1> та <branch2> не потребують вказівки комітів; достатньо дерев.

-X<option>
--strategy-option=<option>

Передайте специфічний для стратегії злиття параметр до стратегії злиття. Див. git-merge[1] для отримання детальної інформації.

ВИХІД

Для успішного злиття, вивід git-merge-tree — це просто один рядок:

<OID of toplevel tree>

Тоді як для конфліктного злиття вихід за замовчуванням має такий вигляд:

<OID дерева верхнього рівня>
<Інформація про конфліктуючий файл>
<Інформаційні повідомлення>

Вони обговорюються окремо нижче.

Однак, є виняток. Якщо передається --stdin, то на початку додається додаткова секція, в кінці — символ NUL, а потім усі секції повторюються для кожного рядка вхідних даних. Таким чином, якщо перше злиття конфліктує, а друге — чисте, результат матиме такий вигляд:

<Стан злиття>
<OID дерева верхнього рівня>
<Інформація про конфліктний файл>
<Інформаційні повідомлення>
NUL
<Стан злиття>
<OID дерева верхнього рівня>
NUL

Стан об’єднання

Це цілочисельний статус, за яким слідує символ NUL. Цілочисельний статус:

0: merge had conflicts
1: merge was clean

OID дерева верхнього рівня

Це об’єкт дерева, який представляє те, що буде витягнуто з робочого дерева в кінці git merge. Якщо виникнуть конфлікти, то файли в цьому дереві можуть мати вбудовані маркери конфліктів. За цим розділом завжди йде символ нового рядка (або NUL, якщо передано -z).

Інформація про конфліктний файл

Це послідовність рядків у форматі

<mode> <object> <stage> <filename>

Ім’я файлу буде взято в лапки, як пояснено для змінної конфігурації core.quotePath (див. git-config[1]). Однак, якщо передано опцію --name-only, режим, об’єкт та етап будуть пропущені. Якщо передано -z, "рядки" завершуються символом NUL замість символу нового рядка.

Інформаційні повідомлення

Цей розділ містить інформаційні повідомлення, зазвичай про конфлікти. Формат розділу значно змінюється залежно від того, чи передано параметр -z.

Якщо передано -z:

Вихідний формат містить нуль або більше записів інформації про конфлікт, кожен з яких має такий вигляд:

<list-of-paths><conflict-type>NUL<conflict-message>NUL

де <список-шляхів> має вигляд

<number-of-paths>NUL<path1>NUL<path2>NUL...<pathN>NUL

і включає шляхи (або імена гілок), на які впливає конфлікт, або інформаційне повідомлення в <conflict-message>. Також <conflict-type> – це стабільний рядок, що пояснює тип конфлікту, наприклад

  • "Автоматичне об’єднання"

  • "КОНФЛІКТ (rename/delete)"

  • "КОНФЛІКТ (підмодулю бракує бази злиття)

  • "КОНФЛІКТ (binary)"

а <conflict-message> — це детальніше повідомлення про конфлікт, яке часто (але не завжди) містить <stable-short-type-description>. Ці рядки можуть змінитися в майбутніх версіях Git. Ось деякі приклади:

  • "Автоматичне об’єднання <file>"

  • "CONFLICT (rename/delete): <oldfile> renamed…​but deleted in…​"

  • "Не вдалося об’єднати підмодуль <підмодуль> (немає бази злиття)

  • "Попередження: неможливо об’єднати бінарні файли: <ім’я файлу>

Якщо -z НЕ передається:

Цей розділ починається з порожнього рядка, щоб відокремити його від попередніх розділів, а потім містить лише інформацію <conflict-message> з попереднього розділу (розділену символами нового рядка). Це нестабільні рядки, які не повинні оброблятися скриптами та призначені лише для використання людиною. Також зверніть увагу, що хоча рядки <conflict-message> зазвичай не містять вбудованих символів нового рядка, іноді вони містять. (Однак повідомлення вільної форми ніколи не матимуть вбудованого символу NUL). Отже, весь блок інформації призначений для читачів-людей як сукупність усіх повідомлень про конфлікти.

СТАТУС ВИХОДУ

Для успішного злиття без конфліктів статус виходу дорівнює 0. Коли злиття має конфлікти, статус виходу дорівнює 1. Якщо злиття не може завершитися (або розпочатися) через якусь помилку, статус виходу відрізняється від 0 або 1 (і результат не визначено). Коли передається --stdin, статус повернення дорівнює 0 як для успішних, так і для конфліктних злиттів, і відрізняється від 0 або 1, якщо не вдається завершити всі запитувані злиття.

ПРИМІТКИ ЩОДО ВИКОРИСТАННЯ

Ця команда призначена для низькорівневої обробки, подібно до git-hash-object[1], git-mktree[1], git-commit-tree[1], git-write-tree[1], git-update-ref[1] та git-mktag[1]. Таким чином, її можна використовувати як частину серії кроків, таких як:

vi message.txt
BRANCH1=refs/heads/test
BRANCH2=main
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) || {
    echo "There were conflicts..." 1>&2
    exit 1
}
NEWCOMMIT=$(git commit-tree $NEWTREE -F message.txt \
    -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT

Зверніть увагу, що коли статус виходу не дорівнює нулю, NEWTREE у цій послідовності міститиме набагато більше виводу, ніж просто дерево.

У разі конфліктів вивід містить ту саму інформацію, яку ви отримали б з git-merge[1]:

ФОРМАТ ВВЕДЕННЯ

git merge-tree --stdin Формат введення повністю текстовий. Кожен рядок має такий формат:

[<base-commit> -- ]<branch1> <branch2>

Якщо один рядок розділено символом --, рядок перед роздільником використовується для визначення бази злиття, а рядок після роздільника описує гілки, що об’єднуються.

ПОМИЛКИ, ЯКИХ СЛІД УНИКНУТИ

НЕ переглядайте отримане дерево верхнього рівня, щоб спробувати знайти файли, які конфліктують; натомість проаналізуйте розділ Conflicted file info. Розбір усього дерева не тільки буде жахливо повільним у великих репозиторіях, але й існує безліч типів конфліктів, які неможливо представити маркерами конфлікту (зміна/видалення, конфлікт режимів, зміна бінарного файлу з обох сторін, конфлікти файлів/каталогів, різні перестановки конфліктів перейменування тощо.)

НЕ інтерпретуйте порожній список Conflicted file info як чисте злиття; перевірте статус завершення. Злиття може мати конфлікти без конфлікту окремих файлів (є кілька типів конфліктів перейменування каталогів, які належать до цієї категорії, а інші також можуть бути додані в майбутньому).

НЕ намагайтеся вгадувати або змушувати користувача вгадувати типи конфліктів зі списку Conflicted file info. Інформації, що міститься в ньому, недостатньо для цього. Наприклад: конфлікти Rename/rename(1to2) (обидві сторони перейменували один і той самий файл по-різному) призведуть до того, що три різні файли матимуть вищі стадії порядку (але кожен має лише одну вищу стадію порядку), без можливості (окрім розділу Informational messages) визначити, які три файли пов’язані між собою. Конфлікти файлів/каталогів також призводять до файлу рівно з однією вищою стадією порядку. Конфлікти possible-in-directory-rename (коли "merge.directoryRenames" не встановлено або встановлено на "conflicts") також призводять до файлу рівно з однією вищою стадією порядку. У всіх випадках розділ Informational messages містить необхідну інформацію, хоча він не призначений для машинного аналізу.

НЕ припускайте, що кожен шлях від Conflicted file info та логічні конфлікти в Informational messages мають відображення "один до одного", а також що існує відображення "один до багатьох" або відображення "багато до одного". Відображення "багато до багатьох" існують, тобто кожен шлях може мати багато типів логічних конфліктів в одному злиття, і кожен тип логічного конфлікту може впливати на багато шляхів.

НЕ припускайте, що всі імена файлів, перелічені в розділі Інформаційні повідомлення, мали конфлікти. Повідомлення можна додавати для файлів, які не мають конфліктів, наприклад, "Автоматичне об’єднання <файл>".

УНИКАЙТЕ взяття OID з Conflicted file info та їх повторного об’єднання для представлення конфліктів користувачеві. Це призведе до втрати інформації. Натомість знайдіть версію файлу, знайдену в OID дерева верхнього рівня, та покажіть її. Зокрема, останнє матиме маркери конфлікту, анотовані оригінальною гілкою/комітом, що об’єднується, та, якщо були перейменування, оригінальною назвою файлу. Хоча ви можете включити оригінальну гілку/коміт до анотацій маркерів конфлікту під час повторного об’єднання, оригінальна назва файлу недоступна з Conflicted file info, і таким чином ви втратите інформацію, яка може допомогти користувачеві вирішити конфлікт.

ЗАСТАРІЛИЙ ОПИС

Згідно з DESCRIPTION та на відміну від решти цієї документації, у цьому розділі описано застарілий режим --trivial-merge.

Окрім необов’язкового параметра --trivial-merge, цей режим не приймає жодних інших параметрів.

Цей режим зчитує три дерева та виводить тривіальні результати злиття та конфліктуючі етапи на стандартний вивід у форматі напіврізниці. Оскільки це було розроблено для скриптів вищого рівня для споживання та злиття результатів назад в індекс, він пропускає записи, що відповідають <branch1>. Результат цієї другої форми подібний до того, що робить тристороння команда git read-tree -m, але замість збереження результатів в індексі, команда виводить записи на стандартний вивід.

Ця форма не лише має обмежене застосування (просте злиття не може обробити злиття вмісту окремих файлів, виявлення перейменування, належну обробку конфліктів каталогів/файлів тощо), але й складний у роботі формат виводу, і він, як правило, буде менш продуктивним, ніж перша форма, навіть при успішних злиттях (особливо при роботі у великих репозиторіях).

GIT

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