українська мова ▾ Topics ▾ Latest version ▾ git-merge-tree last updated in 2.52.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], зокрема:

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

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

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

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

  • й так далі.

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

ОПЦІЇ

--stdin

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

-z

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

--name-only

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

--messages
--no-messages

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

--quiet

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

--allow-unrelated-histories

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

--merge-base=<tree-ish>

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

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

З цією опцією, оскільки база злиття надається безпосередньо, <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, режим, обʼєкт та stage будуть пропущені. Якщо передано -z, "рядки" завершуються символом NUL замість символу нового рядка.

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

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

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

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

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

де <list-of-paths> має вигляд

<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>"

  • "КОНФЛІКТ (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>

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

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

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

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

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

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

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

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

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

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

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

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

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

GIT

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