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

НАЗВА

git-merge — Обʼєднання двох або більше гілок розробки

СИНОПСИС

git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
	[--into-name <branch>] [<commit>…​]
git merge (--continue | --abort | --quit)

ОПИС

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

Припустимо, що існує наступна історія, а поточною гілкою є master:

          A---B---C topic
         /
    D---E---F---G master

Тоді команда git merge topic застосує зміни, внесені у гілці topic з моменту її відгалуження від master (тобто від E) до її поточного коміту (C) поверх гілки master, і збереже результат у новому коміті разом з іменами двох батьківських комітів та повідомленням у журналі від користувача, що описує зміни. Перед операцією ORIG_HEAD встановлюється на кінцеву точку поточної гілки (G).

          A---B---C topic
         /         \
    D---E---F---G---H master

Злиття зупиняється, якщо виникає конфлікт, який неможливо вирішити автоматично, або якщо під час ініціювання злиття було вказано параметр --no-commit. У цей момент ви можете виконати git merge --abort або git merge --continue.

Команда git merge --abort перерве процес злиття та спробує відновити стан, що існував до злиття. Однак, якщо на момент початку злиття були незбережені зміни (а особливо якщо ці зміни були додатково змінені після початку злиття), команда git merge --abort у деяких випадках не зможе відновити початкові (до злиття) зміни. Тому:

Warning
 Не рекомендується виконувати команду git merge, якщо є значні зміни, що не зафіксовані: хоча це й можливо, у разі конфлікту ви можете опинитися в ситуації, з якої важко буде вийти.

ОПЦІЇ

--commit
--no-commit

Виконати обʼєднання та зафіксувати результат. Цю опцію можна використовувати для перевизначення параметра --no-commit.

З параметром --no-commit виконується обʼєднання, але процес зупиняється безпосередньо перед створенням коміту обʼєднання, щоб дати користувачеві можливість перевірити та додатково налаштувати результат обʼєднання перед фіксацією.

Зверніть увагу, що оновлення з переходом вперед (fast-forward) не створюють коміт злиття, тому немає можливості зупинити ці злиття за допомогою --no-commit. Отже, якщо ви хочете переконатися, що ваша гілка не буде змінена або оновлена командою злиття, використовуйте --no-ff разом з --no-commit.

--edit
-e
--no-edit

Перед фіксацією успішного механічного злиття слід запустити редактор, щоб додатково відредагувати автоматично згенероване повідомлення про злиття, завдяки чому користувач зможе пояснити та обґрунтувати це злиття. Для прийняття автоматично згенерованого повідомлення можна використати опцію --no-edit (зазвичай це не рекомендується). Опція --edit (або -e) все ще корисна, якщо ви надсилаєте чернетку повідомлення з опцією -m з командного рядка та хочете редагувати цю чернетку в редакторі.

Старі скрипти можуть розраховувати на те, що раніше користувачеві не дозволялося редагувати повідомлення журналу злиття. При виконанні команди git merge у них відкриватиметься редактор. Щоб полегшити адаптацію таких скриптів до оновленої поведінки, на початку їхнього коду можна встановити значення змінної середовища GIT_MERGE_AUTOEDIT як no.

--cleanup=<режим>

Цей параметр визначає, як повідомлення злиття буде очищено перед комітом. Див. git-commit[1] для отримання додаткової інформації. Крім того, якщо <mode> має значення scissors, scissors буде додано до MERGE_MSG перед передачею до механізму коміту у разі конфлікту злиття.

--ff
--no-ff
--ff-only

Вказує, як обробляється злиття, коли історія, що зливається, вже є нащадком поточної історії. --ff є стандартним значенням, за винятком випадків злиття тегів з анотаціями (та, можливо, підписаних), які не зберігаються у своєму природному місці в ієрархії refs/tags/; у такому випадку використовується значення --no-ff.

За допомогою параметра --ff, коли можливо, виконувати злиття як перемотування вперед (fast-forward) (оновлювати лише вказівник гілки, щоб він відповідав обʼєднаній гілці; не створювати коміт злиття). Якщо неможливо (коли історія обʼєднання не є нащадком поточної історії), створювати коміт злиття.

З опцією --no-ff створюється коміт злиття у всіх випадках, навіть якщо злиття можна було б виконати як перемотування вперед (fast-forward).

З опцією --ff-only, за можливості, виконувати злиття як перемотування вперед. Якщо це неможливо, відмовитися від злиття та завершити роботу з ненульовим статусом.

-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

Підписати отриманий коміт злиття за допомогою GPG. Аргумент <key-id> є необов’язковим, а стандартним значенням є ідентифікатор автора коміту; якщо його вказано, він повинен бути вказаний у параметрі без пробілів. Параметр --no-gpg-sign дозволяє скасувати дію як конфігураційної змінної commit.gpgSign, так і попереднього параметра --gpg-sign.

--log[=<n>]
--no-log

На додачу до назв гілок, додати до повідомлення журналу однорядкові описи не більше ніж <n> фактичних комітів, які об’єднуються. Див. також git-fmt-merge-msg[1].

З опцією --no-log не виводити однорядкові описи з фактичних комітів, що обʼєднуються.

--signoff
--no-signoff

Додає наприкінці повідомлення журналу коміту підпис Signed-off-by, поставлений автором коміту. Значення такого підпису залежить від проєкту, до якого ви робите коміт. Наприклад, він може підтверджувати, що автор коміту має права на публікацію роботи відповідно до ліцензії проєкту або погоджується з певними запевненнями щодо авторів, такими як «Сертифікат походження розробника». (Див. https://developercertificate.org, щоб ознайомитися з тим, що використовується в ядрі Linux та проектах Git.) Зверніться до документації або керівництва проєкту, до якого ви робите внесок, щоб зрозуміти, як підписи використовуються в цьому проєкті.

Опцію --no-signoff можна використовувати для скасування попередньої опції --signoff у командному рядку.

У Git немає (і не буде) змінної конфігурації, яка б стандартно вмикала опцію командного рядка --signoff; детальніше див. елемент commit.signoff у gitfaq[7].

--stat
-n
--no-stat

Показати diffstat в кінці злиття. diffstat також контролюється параметром конфігурації merge.stat.

З опціями -n або --no-stat не показувати статистику змін (diffstat) в кінці злиття.

--compact-summary

Показати компактний зведений опис в кінці злиття.

--squash
--no-squash

Утворити робоче дерево та стан індексу так, ніби відбулося справжнє злиття (за винятком інформації про злиття), але фактично не виконувати коміт, не переміщувати HEAD і не записувати $GIT_DIR/MERGE_HEAD (щоб наступна команда git commit створила коміт злиття). Це дозволяє створити єдиний коміт поверх поточної гілки, ефект якого є таким самим, як злиття іншої гілки (або декількох у випадку «octopus»).

За допомогою --no-squash виконати злиття та зафіксувати результат. Цей параметр можна використовувати для перевизначення --squash.

При використанні опції --squash опція --commit є недопустимою і призведе до помилки.

--verify
--no-verify

Стандартно виконуються хуки pre-merge та commit-msg. Якщо вказано параметр --no-verify, їх виконання пропускається. Див. також githooks[5].

-s <стратегія>
--strategy=<стратегія>

Використовувати вказану стратегію злиття; її можна вказати кілька разів, щоб визначити порядок, у якому вони мають бути випробувані. Якщо опція -s відсутня, замість неї використовується вбудований список стратегій (ort при злитті з однією вершиною, octopus в інших випадках).

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

Передати параметр, що визначає стратегію, безпосередньо до стратегії злиття.

--verify-signatures
--no-verify-signatures

Переконайтеся, що останній коміт бічної гілки, яка об’єднується, підписано дійсним ключем, тобто ключем із дійсним ідентифікатором (uid): у стандартній моделі довіри це означає, що ключ підписання був підписаний ключем, якому довіряють. Якщо останній коміт бічної гілки не підписано дійсним ключем, об’єднання не відбудеться.

--summary
--no-summary

Синоніми до --stat та --no-stat; вони застарілі та будуть видалені в майбутньому.

-q
--quiet

Виконувати дії без виводу повідомлень. Мається на увазі --no-progress.

-v
--verbose

Докладний вивід.

--progress
--no-progress

Явне увімкнення/вимкнення функції «Прогрес». Якщо жодне з цих значень не вказано, хід виконання відображається, якщо стандартний потік помилок підключено до терміналу. Зверніть увагу, що не всі стратегії злиття можуть підтримувати показ ходу виконання.

--autostash
--no-autostash

Перед початком операції автоматично створити тимчасовий запис у сховку, записати його в посилання MERGE_AUTOSTASH і застосувати після завершення операції. Це означає, що операцію можна виконувати на брудному робочому дереві. Однак слід бути обережними: остаточне застосування запису зі сховку після успішного злиття може призвести до серйозних конфліктів.

--allow-unrelated-histories

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

-m <msg>

Встановлює повідомлення коміту, яке буде використовуватися для коміту злиття (якщо такий буде створено).

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

Команду git fmt-merge-msg можна використовувати для встановлення якісного стандартного повідомлення для автоматичних викликів git merge. Автоматизоване повідомлення може містити опис гілки.

--into-name <branch>

Створює стандартне повідомлення про злиття так, ніби злиття відбувається у гілку <branch>, замість назви тієї гілки, до якої насправді відбувається злиття.

-F <файл>
--file=<файл>

Отримати повідомлення коміту, яке буде використано для коміту злиття (якщо такий буде створено).

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

--rerere-autoupdate
--no-rerere-autoupdate

Після того, як механізм rerere повторно використає записане розвʼязання поточного конфлікту для оновлення файлів у робочому дереві, дозвольте йому також оновити індекс результатом розвʼязання. --no-rerere-autoupdate — це гарний спосіб перевірити, що зробив rerere, та виявити потенційні помилки злиття, перш ніж занести результат до індексу за допомогою окремого git add.

--overwrite-ignore
--no-overwrite-ignore

Перезаписувати ігноровані файли в результаті злиття без попередження. Це стандартна поведінка. Для скасування використовуйте опцію --no-overwrite-ignore.

--abort

Перервати поточний процес розвʼязання конфліктів та спробувати відновити стан який був до початку процесу обʼєднання. Якщо запис autostash присутній, застосувати його до робочого дерева.

Якщо на початку злиття були присутні незафіксовані зміни в робочому дереві, git merge --abort у деяких випадках не зможе їх реконструювати. Тому рекомендується завжди зафіксувати або зберегти зміни перед запуском git merge.

git merge --abort є еквівалентом git reset --merge, коли присутній MERGE_HEAD, окрім випадків, коли також присутній MERGE_AUTOSTASH, у цьому випадку git merge --abort застосовує запис stash до робочого дерева, тоді як git reset --merge збереже збережені зміни у списку stash.

--quit

Ігнорувати поточне злиття. Залишити індекс та робоче дерево без змін. Якщо встановлено параметр MERGE_AUTOSTASH, запис stash буде збережено у списку stash.

--continue

Якщо команда git merge зупинилася через конфлікти, ви можете завершити злиття, виконавши команду git merge --continue (див. розділ «ЯК РОЗВʼЯЗУВАТИ КОНФЛІКТИ» нижче).

<commit>...

Коміти, це зазвичай вершини інших гілок, які потрібно обʼєднати з нашою гілкою. Якщо вказати більше одного коміту, буде створено злиття з більш ніж двома батьківськими комітами (яке жартома називають «злиттям Восьминога», Octopus merge).

Якщо в командному рядку не вказано жодного коміту, слід обʼєднати гілки віддаленого відстеження, які поточна гілка налаштована використовувати як своє джерело (upstream). Див. також розділ про налаштування на цій сторінці довідки.

Якщо вказано FETCH_HEAD (і жодного іншого коміту), гілки, записані у файлі .git/FETCH_HEAD під час попереднього виконання команди git fetch для злиття, зливаються з поточною гілкою.

ПЕРЕВІРКИ ПЕРЕД ЗЛИТТЯМ

Перш ніж застосовувати зовнішні зміни, слід привести власні зміни до ладу та зберегти їх локально, щоб у разі конфліктів вони не були загублені. Див. також git-stash[1]. Команди git pull та git merge зупиняться, не виконавши жодних дій, якщо локальні незбережені зміни перекриваються з файлами, які git pull/git merge можуть оновлювати.

Щоб уникнути запису змін, що не стосуються злиття, команди git pull та git merge також припинять роботу, якщо в індексі зареєстровані будь-які зміни порівняно з комітом HEAD. (Залежно від використовуваної стратегії злиття можуть існувати окремі винятки з цього правила, але загалом індекс повинен збігатися з HEAD.)

Якщо всі вказані коміти вже є попередниками HEAD, команда git merge завершиться достроково з повідомленням «Already up to date» («Вже оновлено»).

ЗЛИТТЯ FAST-FORWARD

Часто вершина поточної гілки є пращуром вказаного коміту. Це найпоширеніший випадок, особливо при виконанні команди git pull: ви відстежуєте репозиторій-джерело, не зафіксували жодних локальних змін і тепер хочете оновити репозиторій до нової версії з джерела. У цьому випадку для збереження обʼєднаної історії не потрібен новий коміт; натомість HEAD (разом з індексом) оновлюється, щоб вказувати на вказаний коміт, без створення додаткового коміту злиття.

Цю поведінку можна придушити за допомогою опції --no-ff.

СПРАВЖНЄ ЗЛИТТЯ

За винятком випадків злиття fast-forward (див. вище), гілки, що обʼєднуються, повинні бути повʼязані між собою комітом злиття, в якому обидві гілки є його батьками.

Обʼєднана версія, що враховує зміни з усіх гілок, які потрібно об’єднати, фіксується, а ваш HEAD, індекс та робоче дерево оновлюються відповідно до неї. У робочому дереві можуть бути зміни, якщо вони не перетинаються; під час оновлення вони будуть збережені.

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

  1. Вказівник HEAD залишається незмінним.

  2. Посилання MERGE_HEAD налаштовується так, щоб вказувати на вершину іншої гілки.

  3. Шляхи, які були успішно об’єднані, оновлюються як у файлі індексу, так і у вашому робочому дереві.

  4. У разі конфлікту шляхів індексний файл фіксує до трьох версій: у stage 1 зберігається версія від спільного предка, у stagе 2 — від HEAD, а у stage 3 — від MERGE_HEAD (переглянути stage можна за допомогою команди git ls-files -u). Файли робочого дерева містять результат операції злиття, тобто результати тристороннього злиття зі знайомими маркерами конфлікту <<< === >>>.

  5. Створюється посилання з іменем AUTO_MERGE, яке вказує на дерево, що відповідає поточному вмісту робочого дерева (включно з маркерами конфліктів для текстових конфліктів). Зверніть увагу, що це посилання створюється лише у разі використання стратегії злиття ort (зазвичай).

  6. Жодних інших змін не вноситься. Зокрема, локальні зміни, які ви мали до початку злиття, залишаться незмінними, а записи індексу для них залишаться такими, якими вони були, тобто збігатимуться з HEAD.

Якщо ви спробували злиття, яке призвело до складних конфліктів, і хочете почати спочатку, ви можете відновити його за допомогою git merge --abort.

ОБʼЄДНАННЯ ТЕГА

Під час злиття тегу з анотацією (і, можливо, з підписом) Git завжди створює коміт злиття, навіть якщо можливе злиття методом «fast-forward», а шаблон повідомлення про коміт заповнюється текстом тегу. Крім того, якщо тег підписано, результат перевірки підпису відображається у вигляді коментаря в шаблоні повідомлення. Див. також git-tag[1].

Якщо ви хочете просто інтегрувати зміни, що передують коміту, який випадково має тег, наприклад, для синхронізації з версією випуску upstream, вам, можливо, не варто створювати зайвий коміт злиття.

У такому випадку ви можете самостійно «розгорнути» тег перед тим, як передати його команді git merge, або вказати параметр --ff-only, якщо у вас немає власних змін. Наприклад:

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

ЯК ПОДАЮТЬСЯ КОНФЛІКТИ

Під час злиття файли робочого дерева оновлюються, щоб відобразити результат злиття. Серед змін, внесених до версії спільного предка, ті, що не перекриваються (тобто ви змінили частину файлу, тоді як інша сторона залишила цю частину без змін, або навпаки), включаються до кінцевого результату дослівно. Однак, коли обидві сторони внесли зміни до однієї й тієї ж частини, Git не може довільно вибрати одну сторону замість іншої і просить вас виправити ситуацію, лишивши те, що обидві сторони зробили з цією частиною.

Зазвичай Git використовує той самий стиль, що й програма «merge» з набору RCS, для відображення такого фрагмента з конфліктом, наприклад:

Ось рядки, які або залишилися без змін порівняно зі спільним
предком, або розвʼязані без конфліктів, оскільки змінилася лише одна сторона,
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
<<<<<<< ваш:sample.txt
Розвʼязання конфліктів — це складно;
Ходімо на закупи.
=======
Git спрощує розв’язання конфліктів.
>>>>>>> їхній:sample.txt
А ось ще один рядок, який розв’язано без конфліктів або який залишився без змін.

Місце, де відбулася пара суперечливих змін, позначено маркерами <<<<<<<, ======= та >>>>>>>. Частина перед ======= зазвичай належить вам, а частина після — іншій стороні.

У стандартному форматі не показується, що саме було написано в оригінальному тексті у місці, де виникли розбіжності. Неможливо визначити, скільки рядків було видалено та замінено коментарем Барбі у вашій частині тексту. Єдине, що можна зрозуміти, — це те, що у вашій частині йдеться про те, що це складно і ви б воліли піти на закупи, тоді як у частині опонента стверджується, що це легко.

Альтернативний стиль можна використовувати, встановивши змінну конфігурації merge.conflictStyle на diff3 або zdiff3. У стилі diff3 вищезгаданий конфлікт може виглядати так:

Ось рядки, які або залишилися без змін порівняно зі спільним
предком, або розвʼязані без конфліктів, оскільки змінилася лише одна сторона,
<<<<<<< ваш:sample.txt
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
Розвʼязання конфліктів — це складно;
Ходімо на закупи.
||||||| базовий:sample.txt
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
Розвʼязання конфліктів — це складно.
=======
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
Git спрощує вирішення конфліктів.
>>>>>>> їхній:sample.txt
А ось ще один рядок, який розв’язано без конфліктів або який залишився без змін.

в той час як в zdiff3 це може виглядати так:

Ось рядки, які або залишилися без змін порівняно зі спільним
предком, або розвʼязані без конфліктів, оскільки змінилася лише одна сторона,
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
<<<<<<< ваш:sample.txt
Розвʼязання конфліктів — це складно;
Ходімо на закупи.
||||||| base:sample.txt
або розвʼязані без конфліктів, оскільки обидві сторони змінилися однаково.
Розвʼязання конфліктів — це складно.
=======
Git спрощує вирішення конфліктів.
>>>>>>> їхній:sample.txt
А ось ще один рядок, який розв’язано без конфліктів або який залишився без змін.

Окрім маркерів <<<<<<<, ======= та >>>>>>>, тут використовується ще один маркер |||||||, за яким йде оригінальний текст. З цього можна зрозуміти, що в оригіналі йшлося про констатацію факту, і ваша сторона просто погодилася з цим твердженням та поступилася, тоді як інша сторона намагалася зайняти більш позитивну позицію. Іноді, переглянувши оригінал, можна знайти краще рішення.

ЯК РОЗВʼЯЗУВАТИ КОНФЛІКТИ

Після виявлення конфлікту ви можете зробити дві речі:

  • Відмовитися від злиття. Єдине, що потрібно зробити для прибирання, — це скинути файл індексу до коміту HEAD, щоб скасувати stage 2, та прибрати зміни у робочому дереві, внесені stage 2 і 3; для цього можна використати команду git merge --abort.

  • Розвʼязати конфлікти. Git позначить конфлікти у робочому дереві. Відредагуйте файли та додайте їх до індексу за допомогою команди git add. Використовуйте git commit або git merge --continue, щоб завершити операцію. Остання команда перевіряє, чи триває (перерване) злиття, перш ніж запускати git commit.

Ви можете розвʼязати конфлікт за допомогою різних інструментів:

  • Використайте mergetool. git mergetool запускає графічний інтерфейс mergetool, який допоможе вам виконати злиття.

  • Перегляньте diff. Команда git diff покаже тристоронню різницю, виділивши зміни як у версії HEAD, так і в версії MERGE_HEAD. Команда git diff AUTO_MERGE покаже, які зміни ви внесли до цього моменту для вирішення текстових конфліктів.

  • Перегляньте відмінності з кожної гілки. git log --merge -p <шлях> спочатку покаже відмінності для версії HEAD, а потім для версії MERGE_HEAD.

  • Подивіться на оригінали. git show :1:filename показує спільного предка, git show :2:filename показує версію HEAD, а git show :3:filename показує версію MERGE_HEAD.

ПРИКЛАДИ

  • Злиття гілок fixes та `enhancements ` у поточну гілку, шляхом використання стратегії злиття "octopus":

    $ git merge fixes enhancements

  • Злиття гілки obsolete у поточну гілку, використовуючи стратегію злиття ours:

    $ git merge -s ours obsolete

  • Злиття гілки maint з поточною гілкою, але без автоматичного створення нового коміту:

    $ git merge --no-commit maint

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

    Не слід зловживати цією опцією, щоб непомітно внести суттєві зміни в коміт злиття. Невеликі виправлення, такі як підвищення номера версії, є прийнятними.

СТРАТЕГІЇ ЗЛИТТЯ

Механізм злиття (команди git merge та git pull) дозволяє вибирати бекенд-«стратегії злиття» за допомогою опції -s. Деякі стратегії також можуть приймати власні опції, які можна передати, надаючи аргументи -X<опція> командам git merge та/або git pull.

ort

Це стандартна стратегія злиття при витягуванні або злитті однієї гілки. Ця стратегія дозволяє об’єднати лише дві вершини за допомогою алгоритму тристороннього злиття. Коли існує більше ніж один спільний предок, який можна використати для тристороннього злиття, вона створює злите дерево спільних предків і використовує його як дерево-орієнтир для тристороннього злиття. За результатами тестів, проведених на реальних комітах злиття, взятих з історії розробки ядра Linux 2.6, це призводить до меншої кількості конфліктів злиття без створення помилкових злиттів. Крім того, ця стратегія може виявляти та обробляти злиття, що містять перейменування. Вона не використовуватиме виявлені копії. Назва цього алгоритму є акронімом («Ostensibly Recursive’s Twin») і походить від того, що він був написаний як заміна попереднього стандартного алгоритму, recursive.

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

Стратегія ort може приймати такі варіанти:

ours

Ця опція змушує систему автоматично розвʼязувати конфлікти між фрагментами коду, надаючи перевагу «нашій» версії. Зміни з іншого дерева, які не суперечать нашій версії, враховуються в результаті злиття. У випадку з бінарним файлом весь вміст береться з нашої версії.

Це не слід плутати зі стратегією злиття ours, яка взагалі не враховує вміст іншого дерева. Вона відкидає всі зміни, внесені в іншому дереві, і вважає, що «наша» історія містить усе, що там відбувалося.

theirs

Це протилежність параметру ours; зверніть увагу, що, на відміну від ours, не існує стратегії злиття theirs, з якою можна було б сплутати цей параметр злиття.

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol

Для цілей тристороннього злиття рядки, що містять вказаний тип змін пробілів, розглядаються як незмінені. Зміни пробілів, що поєднуються з іншими змінами в рядку, не ігноруються. Див. також git-diff[1] -b, -w, --ignore-space-at-eol та --ignore-cr-at-eol.

  • Якщо «їхня» версія передбачає лише зміну пробілів у рядку, використовується «наша» версія;

  • Якщо «наша» версія містить зміни пробілів, але «їхня» версія містить суттєві зміни, використовується «їхня» версія;

  • В іншому випадку обʼєднання відбувається у звичайному порядку.

renormalize

Ця опція виконує перевірку та реєстрацію всіх трьох стадій будь-якого файлу, який потребує тристороннього злиття. Цю опцію слід використовувати під час злиття гілок із різними фільтрами очищення або правилами нормалізації кінців рядків. Детальніше див. розділ «Злиття гілок із різними атрибутами checkin/checkout» у статті gitattributes[5].

no-renormalize

Вимикає опцію renormalize. Це замінює змінну конфігурації merge.renormalize.

find-renames[=<n>]

Вимкає виявлення перейменувань, за бажанням встановивши поріг схожості. Це значення є типовим. Воно має пріоритет над змінною конфігурації merge.renames. Див. також git-diff[1] --find-renames.

rename-threshold=<n>

Застарілий синонім до find-renames=<n>.

no-renames

Вимикає виявлення перейменування. Перевизнає змінну конфігурації merge.renames. Див. також git-diff[1] --no-renames.

histogram

Застарілий синонім до diff-algorithm=histogram.

patience

Застарілий синонім до diff-algorithm=patience.

diff-algorithm=(histogram|minimal|myers|patience)

Під час злиття використовувати інший алгоритм порівняння, що допоможе уникнути помилкових злиттів, які виникають через неважливі збіги рядків (наприклад, дужки з різних функцій). Див. також git-diff[1] --diff-algorithm. Зверніть увагу, що для ort стандартним значенням є diff-algorithm=histogram, тоді як для звичайних порівнянь наразі використовується значення параметра конфігурації diff.algorithm.

subtree[=<path>]

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

recursive

Тепер це синонім до ort. Це стратегія була альтернативною реалізацією до версії 2.49.0, але була перенаправлена на ort у версії 2.50.0. Попередня рекурсивна стратегія була стандартною стратегією для розвʼязання для двох вершин з Git версії 0.99.9k до версії 2.33.0.

resolve

Може розвʼязувати лише дві гілки (тобто поточну гілку та іншу гілку, з якої було виконано злиття) за допомогою алгоритму тристороннього злиття. Намагається ретельно виявляти неоднозначності, пов’язані з перехресним злиттям. Не підтримує перейменування.

octopus

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

ours

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

subtree

Це модифікована стратегія ort. Під час обʼєднання дерев A та B, якщо B відповідає піддереву A, B спочатку коригується відповідно до структури дерева A, замість того, щоб зчитувати дерева на одному рівні. Це коригування також виконується для дерева спільного предка.

У стратегіях, що використовують тристороннє злиття (включно зі стандартною стратегією ort), якщо зміна була внесена в обох гілках, але згодом скасована в одній із них, ця зміна все одно буде присутня в результаті злиття; деякі користувачі вважають таку поведінку заплутаною. Це відбувається тому, що під час злиття враховуються лише кінцеві точки гілок та базова точка злиття, а не окремі коміти. Тому алгоритм злиття розглядає скасовану зміну як відсутність будь-якої зміни взагалі і замінює її зміненою версією.

КОНФІГУРАЦІЯ

branch.<name>.mergeOptions

Встановлює стандартні параметри для злиття у гілку <назва>. Синтаксис та підтримувані параметри такі ж, як і у git merge, але значення параметрів, що містять пробіли, наразі не підтримуються.

Все, що знаходиться вище цього рядка в цьому розділі, не включено до документації git-config[1]. Наступний вміст такий самий, як і той, що знаходиться там:

merge.conflictStyle

Вкажіть стиль, у якому конфліктні фрагменти записуються у файли робочого дерева під час обʼєднання. Стандартне значення — "merge", показує маркер конфлікту <<<<<<<, зміни, внесені однією стороною, маркер =======, зміни, внесені іншою стороною, а потім маркер >>>>>>>. Альтернативний стиль, "diff3", додає маркер ||||||| та оригінальний текст перед маркером =======. Стиль "merge", як правило, створює менші області конфлікту, ніж diff3, як через виключення оригінального тексту, так і тому, що коли підмножина рядків збігається з двох сторін, вони просто витягуються з області конфлікту. Інший альтернативний стиль, "zdiff3", подібний до diff3, але видаляє з області конфлікту рядки, що збігаються з двох сторін, коли ці рядки, що збігаються, зʼявляються поблизу початку або кінця області конфлікту.

merge.defaultToUpstream

Якщо команда merge викликається без аргументу commit, виконується злиття гілок upstream, налаштованих для поточної гілки, з використанням їхніх останніх значень, збережених у гілках remote-tracking. Перевіряються значення branch.<current branch>.merge, які називають гілки на віддаленому сервері, названому branch.<current-branch>.remote, а потім вони зіставляються за допомогою remote.<remote>.fetch з відповідними гілками віддаленого відстеження, і вершини цих гілок відстеження зливаються. Стандартне значення — true.

merge.ff

Стандартно Git не створює додаткового коміту злиття під час злиття коміту, який є нащадком поточного коміту. Натомість вершина поточної гілки переноситься вперед (fast-forward). Якщо для цієї змінної встановлено значення false, Git створює додатковий коміт злиття в такому випадку (що еквівалентно введенню опції --no-ff у командному рядку). Якщо встановлено значення only, дозволяються лише такі злиття з переміщенням вперед (що еквівалентно введенню опції --ff-only у командному рядку).

merge.verifySignatures

Якщо це значення true, це еквівалентно опції командного рядка --verify-signatures. Див. git-merge[1] для отримання детальної інформації.

merge.branchdesc

Окрім назв гілок, заповнювати повідомлення журналу текстом опису гілок, повʼязаним із ними. Стандартне значення — false.

merge.log

Окрім назв гілок, заповнювати повідомлення журналу щонайбільше вказаною кількістю однорядкових описів з фактичних комітів, що обʼєднуються. Станадртне значення — false, а true є синонімом 20.

merge.suppressDest

Якщо додати до цієї багатозначної конфігураційної змінної шаблон, що відповідає назвам гілок інтеграції, у титулі стандартного повідомлення про злиття, яке генерується під час злиття в ці гілки інтеграції, буде опущено фрагмент «into <branch-name>».

Елемент із порожнім значенням можна використовувати для очищення списку шаблонів, накопичених з попередніх записів конфігурації. Якщо змінна merge.suppressDest не визначена, для зворотної сумісності стандартно використовується значення master.

merge.renameLimit

Кількість файлів, які слід враховувати під час вичерпної перевірки на перейменування під час злиття. Якщо значення не вказано, зазвичай використовується значення diff.renameLimit. Якщо не вказано ані merge.renameLimit, ані diff.renameLimit, зазвичай використовується значення 7000. Цей параметр не діє, якщо виявлення перейменувань вимкнено.

merge.renames

Чи виявляє Git перейменування. Якщо встановлено значення false, виявлення перейменування вимкнено. Якщо встановлено значення true, базове виявлення перейменування ввімкнено. Стандартне значення визначається в diff.renames.

merge.directoryRenames

Чи виявляє Git перейменування тек, що впливає на те, як під час злиття обробляються нові файли, додані до теки на одному боці історії, якщо ця тека була перейменована на іншому боці історії. Можливі значення:

false

Виявлення перейменування тек вимкнено, тобто такі нові файли залишаться у старій теці.

true

Виявлення перейменування тек увімкнено, тобто такі нові файли будуть переміщені до нової теки.

conflict

Для таких шляхів буде повідомлено про конфлікт.

Якщо merge.renames має значення false, merge.directoryRenames ігнорується та обробляється як false. Стандартне значення —conflict.

merge.renormalize

Повідомте Git, що канонічне представлення файлів у репозиторії з часом змінилося (наприклад, попередні коміти записували текстові файли із закінченнями рядків CRLF, але новіші використовують закінчення рядків LF). У такому репозиторії, для кожного файлу, де потрібне тристороннє злиття вмісту, Git може конвертувати дані, записані в комітах, у канонічну форму перед виконанням злиття, щоб зменшити непотрібні конфлікти. Для отримання додаткової інформації див. розділ «Злиття гілок із різними атрибутами checkin/checkout» в gitattributes[5].

merge.stat

Визначає, що друкувати (якщо взагалі щось) між ORIG_HEAD і результатом злиття наприкінці процесу злиття. Можливі значення:

false

Нічого не показувати.

true

Показати git diff --diffstat --summary ORIG_HEAD.

compact

Показати git diff --compact-summary ORIG_HEAD.

але будь-яке нерозпізнане значення (наприклад, значення, додане майбутньою версією Git) сприймається як true, а не викликає помилку. Стандартне значення —true.

merge.autoStash

Якщо встановлено значення true, автоматично створюється тимчасовий запис stash перед початком операції та застосовується після її завершення. Це означає, що ви можете запустити злиття на некоректному робочому дереві. Однак використовуйте обережно: остаточне застосування stash після успішного злиття може призвести до нетривіальних конфліктів. Цей параметр можна перевизначити параметрами --no-autostash та --autostash параметра git-merge[1]. Стандартне значення — false.

merge.tool

Керує тим, який інструмент злиття використовується git-mergetool[1]. У списку нижче наведено дійсні вбудовані значення. Будь-яке інше значення розглядається як власний інструмент злиття та вимагає визначення відповідної змінної mergetool.<tool>.cmd.

merge.guitool

Керує тим, який інструмент злиття використовується git-mergetool[1], коли вказано прапорець -g/--gui. У списку нижче наведено дійсні вбудовані значення. Будь-яке інше значення розглядається як власний інструмент злиття та вимагає визначення відповідної змінної mergetool.<guitool>.cmd.

Warning

Missing uk/config/{build_dir}/mergetools-merge.adoc

See original version for this content.
merge.verbosity

Контролює обсяг виводу, що відображається стратегією рекурсивного злиття. Рівень 0 не виводить нічого, окрім остаточного повідомлення про помилку, якщо виявлено конфлікти. Рівень 1 виводить лише конфлікти, 2 виводить конфлікти та зміни файлів. Рівень 5 і вище виводить інформацію для налагодження. Стандартно використовується рівень 2. Може бути перевизначений змінною середовища GIT_MERGE_VERBOSITY.

merge.<driver>.name

Визначає зрозумілу для людини назву для власного драйвера злиття низького рівня. Див. gitattributes[5] для отримання детальної інформації.

merge.<driver>.driver

Визначає команду, яка реалізує власний драйвер злиття низького рівня. Див. gitattributes[5] для отримання детальної інформації.

merge.<driver>.recursive

Визначає драйвер злиття низького рівня, який буде використовуватися під час виконання внутрішнього злиття між спільними предками. Див. gitattributes[5] для отримання детальної інформації.

ДИВ. ТАКОЖ

git-fmt-merge-msg[1], git-pull[1], gitattributes[5], git-reset[1], git-diff[1], git-ls-files[1], git-add[1], git-rm[1], git-mergetool[1]

GIT

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