українська мова ▾ Topics ▾ Latest version ▾ git-merge last updated in 2.51.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 виконайте злиття та зупиніть його безпосередньо перед створенням коміту злиття, щоб дати користувачеві можливість перевірити та додатково налаштувати результат злиття перед комітом.

Зверніть увагу, що оновлення вперед не створюють коміту злиття, і тому немає способу зупинити ці злиття за допомогою --no-commit. Таким чином, якщо ви хочете переконатися, що ваша гілка не буде змінена або оновлена командою merge, використовуйте --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, коли можливо, виконувати злиття як перемотування вперед (оновлювати лише вказівник гілки, щоб він відповідав об’єднаній гілці; не створювати коміт злиття). Якщо неможливо (коли історія об’єднання не є нащадком поточної історії), створювати коміт злиття.

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

З опцією --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

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

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

--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 не дозволено і призведе до невдачі.

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

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

--summary
--no-summary

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

-q
--quiet

Працюйте тихо. Мається на увазі --no-progress.

-v
--verbose

Будьте багатослівними.

--progress
--no-progress

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

--autostash
--no-autostash

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

--allow-unrelated-histories

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

-m <msg>

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

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

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

--into-name <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

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

Якщо на початку злиття були присутні незафіксовані зміни в робочому дереві, 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).

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

Коли вказано 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 завершить роботу раніше терміну з повідомленням "Вже оновлено".

ШВИДКЕ ЗЛИТТЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У такому випадку ви можете самостійно "розгорнути" тег перед тим, як передати його до 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 вищезгаданий конфлікт може виглядати так:

Ось рядки, які або не змінилися від спільного
предка, або чисто вирішені, оскільки змінилася лише одна сторона,
<<<<<<< yours:sample.txt
або чисто вирішені, оскільки обидві сторони змінилися однаково.
Вирішення конфліктів складне;
давайте підемо за покупками.
||||||| base:sample.txt
або чисто вирішені, оскільки обидві сторони змінилися однаково.
Вирішення конфліктів складне.
=======
або чисто вирішені, оскільки обидві сторони змінилися однаково.
Git спрощує вирішення конфліктів.
>>>>>>> theirs:sample.txt
А ось ще один рядок, який чисто вирішений або незмінений.

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

Ось рядки, які або не змінилися від спільного
предка, або чисто вирішені, оскільки змінилася лише одна сторона,
або чисто вирішені, оскільки обидві сторони змінилися однаково.
<<<<<<< yours:sample.txt
Вирішення конфліктів складне;
давайте підемо за покупками.
||||||| base:sample.txt
або чисто вирішені, оскільки обидві сторони змінилися однаково.
Вирішення конфліктів складне.
=======
Git спрощує вирішення конфліктів.
>>>>>>> theirs:sample.txt
А ось ще один рядок, який чисто вирішений або незмінений.

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

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

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

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

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

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

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

  • Перегляньте різниці. 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.

ПРИКЛАДИ

  • Об’єднати гілки виправлення та покращення поверх поточної гілки, створивши злиття типу "осьминог":

    $ 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

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

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

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

ours

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

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

theirs

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

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

Це запускає віртуальне отримання та повернення всіх трьох етапів будь-якого файлу, який потребує тристороннього злиття. Цей параметр призначений для використання під час об’єднання гілок з різними фільтрами очищення або правилами нормалізації кінця рядка. Див. "Об’єднання гілок з різними атрибутами реєстрації/вивантаження" в 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>]

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

recursive

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

resolve

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

octopus

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

ours

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

subtree

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

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

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

branch.<name>.mergeOptions

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

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

Warning

Missing uk/config/merge.adoc

See original version for this content.

ДИВ. ТАКОЖ

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]