Merge-конфлікти: причини й розв'язання

Що таке merge-конфлікт і чому Git на ньому зупиняється?

Конфлікт — це ситуація, коли дві гілки по-різному змінили те саме місце в файлі, і Git відмовляється вгадувати, чия правка головніша. Це не поломка інструмента й не помилка: Git чесно каже, що не має критерію обрати між двома варіантами, і передає рішення людині. Механізм у тому, що Git порівнює текст рядок за рядком, а не розуміє зміст коду, тож будь-яке розходження байтів в одній ділянці для нього рівнозначне. Практично для AQA це щоденна річ: тести живуть у тому ж репозиторії, що й продукт, гілки довго висять у ревʼю, і десятки людей чіпають ті самі фікстури та page-object-и. Хто знає, що конфлікт штатний, розвʼязує його за хвилину; хто ні — панікує або мовчки псує чужі зміни.

Що таке тристороннє злиття і до чого тут база злиття?

Тристороннє злиття (three-way merge) — це спосіб, у який Git зʼєднує гілки, спираючись не на дві, а на три версії файлу. Крім вашої гілки та тієї, яку ви вливаєте, він бере ще їхнього спільного предка — коміт, від якого гілки розійшлися; це і є база злиття (merge base). Порівнюючи кожну гілку з базою, Git бачить, хто саме що змінив відносно спільної точки, і завдяки цьому вирішує більшість випадків автоматично. Якщо рядок правила лише одна сторона — правка береться без питань; якщо обидві змінили його однаково — беруться збіжні варіанти; якщо ж обидві правили той самий рядок по-різному — критерію немає, і Git зупиняється. Без бази він не відрізнив би «додав новий рядок» від «видалив чужий», тож саме спільний предок робить злиття осмисленим.

Дві людини правили один файл. Чому конфлікту може й не бути?

Бо Git конфліктує не за файлом, а за конкретними ділянками рядків. Якщо одна людина чіпала початок файлу, а інша — кінець, правки не перетинаються, і Git спокійно зіллє обидві без жодного втручання. Поширена помилка новачка — думати «ми обоє редагували один файл, отже, буде конфлікт»; це червоний прапорець на співбесіді, бо показує нерозуміння механізму. Водночас працює й зворотне: конфлікт можливий навіть без прямого перетину рядок-у-рядок, якщо правки надто близькі. Git оперує блоками (hunk) з невеликим контекстом навколо зміни, і сусідні правки іноді не вміщаються в один блок безболісно. Тож правильна модель — «конфлікт там, де розійшлися близькі рядки», а не «конфлікт там, де спільний файл».

Як читати маркери конфлікту у файлі?

Коли Git наштовхується на конфлікт, він не відкочує роботу, а лишає файл на диску, вставивши в спірне місце обидві версії між трьома маркерами. <<<<<<< HEAD відкриває вашу версію — те, що зараз у гілці, куди ви зливаєте. Рядок ======= розділяє два варіанти. Нижче йде версія з гілки, яку ви вливаєте, а закриває блок >>>>>>> з назвою цієї гілки (або з хешем коміту, якщо це rebase чи cherry-pick). Розвʼязати конфлікт означає прибрати всі три маркери й лишити той текст, який справді має бути у фінальній версії. Ключове: це не механічний вибір «ліве або праве» — часто правильна відповідь поєднує обидва боки, наприклад бере URL із чужої гілки, але зберігає нову константу, якої у вашій версії не було.

Опишіть повний цикл розвʼязання merge-конфлікту.

Він складається з трьох кроків, і їхня послідовність — не формальність, а протокол Git. Спершу правка: відкриваєте кожен конфліктний файл, прибираєте маркери й доводите вміст до правильного фінального стану, спираючись на розуміння коду обох сторін. Далі git add кожного розвʼязаного файлу — саме він знімає файл зі списку невзгоджених. Нарешті git commit, який фіксує злиття. Знайти всі проблемні файли просто: git status показує їх у секції «Unmerged paths», а git diff виводить самі конфліктні блоки. Поки хоч один файл лишається невзгодженим, злиття вважається незавершеним, і комітити ще рано. Сильний кандидат називає причину конфлікту, читає маркери й описує саме цей цикл, а не завчені команди.

Який особливий сенс має git add під час розвʼязання конфлікту?

У звичайному циклі git add просто кладе зміни у staging, але в контексті конфлікту він додатково означає «цей файл я розвʼязав». Git прибирає файл зі списку «Unmerged paths» і починає вважати його готовим до коміту. Тобто add тут — це сигнал інструменту, що ви завершили примирення саме цього файлу, а не лише технічна підготовка до коміту. Практичний наслідок: доки ви не додали всі конфліктні файли, Git не дасть завершити злиття штатним комітом і триматиме вас у стані «merging». Тому корисна звичка — після кожної правки прогнати git status і переконатися, що список невзгоджених файлів справді порожніє, а не лишає забутий файл.

Що створює git commit після розвʼязання і чим цей коміт особливий?

Коли всі конфлікти позначені розвʼязаними, git commit створює коміт злиття (merge commit) — особливий коміт із двома батьками, який фіксує сам факт зʼєднання двох гілок. Git навіть підставляє готове повідомлення на кшталт Merge branch 'feature/qa-env', бо знає контекст. Два батьки — це те, що відрізняє merge-коміт від звичайного: за ним видно, що в цій точці історія двох ліній зійшлася. Саме тому після нього відкотити злиття вже не можна через merge --abort — воно завершене, і для скасування потрібен revert цього merge-коміту. Для AQA це важливо розуміти, коли розбираєш історію гілки з тестами: merge-коміт лишає слід злиття, тоді як rebase такого сліду не залишає.

Чим git merge --abort відрізняється від git reset --hard?

git merge --abort — це аварійна кнопка, що повністю відкочує незавершене злиття й повертає робочу директорію рівно в стан до git merge: жодних напівзлитих файлів і маркерів, наче ви й не починали. Саме її треба назвати на співбесіді у відповідь на «а якщо злиття пішло не так». Різниця з reset --hard принципова: merge --abort знає про контекст злиття й акуратно скасовує саме його, тоді як reset --hard — грубе скидання стану, яким легко знести й ваші власні незакомічені зміни поруч. Ще один нюанс: merge --abort працює, лише поки злиття не закомічене; після commit відкочувати доведеться інакше. Типовий здоровий сценарій — побачити десяток конфліктів у файлах, яких ви не торкались, зробити merge --abort, підтягнути свіжий main і зливати вже свідомо.

Що робити з конфліктом у package-lock.json?

Не мерджити руками, а перегенерувати. Lock-файли (package-lock.json, yarn.lock, pnpm-lock.yaml) — автогенеровані файли на тисячі рядків, що фіксують точні версії всього дерева залежностей, тож коли дві гілки додали різні пакети, їхні lock-файли майже гарантовано конфліктують на десятках рядків. Ручне злиття тут і безнадійне (граф залежностей у голові не втримати), і небезпечне: правка легко зробить lock неконсистентним із package.json, і збірка почне поводитись непередбачувано. Правильний підхід — спершу осмислено розвʼязати конфлікт у самому package.json, де рядків мало й вони зрозумілі, а потім дати менеджеру пакетів заново вивести коректний lock однією командою install. Джерело істини — package.json, а lock лише його похідна. Коротка точна відповідь «перегенерувати через install» одразу вирізняє того, хто справді працював у команді.

Чим відрізняються конфлікти при merge і при rebase?

При git merge конфлікт виникає один раз: Git намагається зʼєднати кінцеві стани двох гілок, показує всі розбіжності разом, ви розвʼязуєте їх і робите один merge-коміт. При git rebase Git переносить ваші коміти по одному на нову базу, ніби ви написали їх заново поверх свіжого main, тому конфлікт може спливати на кожному вашому коміті окремо: розвʼязали перший — git rebase --continue, наткнулися на другий — знову правка й --continue. Це дратує, бо той самий рядок іноді конфліктує кілька разів (кожен ваш коміт його чіпав), зате історія виходить лінійною, без merge-коміту. Аварійний вихід відрізняється відповідно: git merge --abort проти git rebase --abort. Вибір між ними — це вибір між правдивою історією зі слідами злиттів і чистою лінійною історією, а конфлікти лише один із факторів.

Чому під час rebase значення --ours і --theirs перевертаються?

Бо rebase накладає ваші коміти на нову базу й «своєю» стороною вважає саме базу, а не вашу гілку. При звичайному merge --ours — це ваша поточна гілка, а --theirs — та, яку вливаєте. Під час rebase логіка обертається: ours стає базою (наприклад, свіжий main), а theirs — вашим комітом, який Git у цей момент накладає. Це класична пастка: людина за звичкою робить git checkout --ours, розраховуючи лишити свою правку, а насправді бере чужу. Практичний висновок простий — не покладайтеся на --ours/--theirs наосліп під час rebase, а дивіться на фактичний зміст рядків. Команди git checkout --ours <файл> і git checkout --theirs <файл> корисні, коли ви точно вирішили взяти один бік цілком, але їхнє значення треба щоразу звіряти з контекстом операції.

Тест упав на CI одразу після «розвʼязаного» злиття зі скаргою на синтаксис. Що найімовірніше?

Найімовірніше, в одному з файлів лишився забутий маркер конфлікту — найчастіше самотній рядок =======, який ви не помітили. Такий рядок — синтаксична помилка в майже будь-якій мові, тож білд падає ще до запуску тестів, хоча локально «все виглядало розвʼязаним». Причина зазвичай у тому, що редактор показав частину конфліктів, а один блок лишився поза увагою, або файлів було багато й один пропустили. Тому залізне правило — перед комітом прогнати по всьому дереву пошук <<<<<<<, ======= і >>>>>>>. Кнопки редактора «Accept Current / Incoming / Both» зручні для правки тексту, але відповідальність за те, що жоден маркер не лишився, усе одно на вас. Це дешева перевірка, яка економить червоний пайплайн і зіпсований час колег.

Що таке git rerere і коли він корисний?

git rerere (reuse recorded resolution) — механізм, що запамʼятовує, як саме ви розвʼязали конкретний конфлікт, і застосовує це рішення автоматично, коли той самий конфлікт трапляється знову. Найбільше він рятує під час довгих rebase, де один і той самий рядок конфліктує повторно на кожному з ваших комітів: замість розвʼязувати його вручну знову й знову, ви робите це раз, а далі Git підставляє готове. Це інструмент рівня middle — новачку його знати не обовʼязково, але згадати про існування на співбесіді корисно. Він не змінює саму природу конфлікту, а лише прибирає механічне повторення однакової ручної роботи. Увімкнути його треба явно, після чого Git починає тихо накопичувати ваші розвʼязання.

Як у команді зменшити кількість merge-конфліктів?

Найдешевший конфлікт — той, якого не сталося, і працює тут дисципліна, а не магія. Перше — маленькі короткоживучі PR: що довше гілка живе окремо від main, то далі розходяться історії й то болючіший конфлікт наприкінці; гілка на день зіллється майже завжди, гілка на три тижні з рефакторингом півпроєкту — гарантований бій. Друге — часта синхронізація з базовою гілкою: регулярно підтягуйте main, щоб ловити чужі зміни малими порціями, поки їх легко примирити. Розвʼязати три рядки сьогодні простіше, ніж триста післязавтра. Третє — домовленості про власність коду й автоформатер, щоб не конфліктувати на пробілах і лапках; особливо це стосується спільних config, хелперів і централізованих локаторів у тестах — це гарячі точки, які варто чіпати обережно й узгоджено.

Колега радить при кожному конфлікті видаляти гілку й переробляти з нуля. Чому це погана порада?

Бо вона лікує неіснуючу хворобу: штатний конфлікт розвʼязується за хвилину через правку, git add і git commit, а перестворення гілки викидає вже зроблену роботу й час. Паніка й «видалю все та почну заново» — ознака нерозуміння механізму, а не складності задачі. Конфлікт не псує ваші коміти: вони на місці, Git лише просить розсудити одне спірне місце. Якщо масштаб конфлікту справді лякає, правильна відповідь — не знищувати гілку, а зробити merge --abort, підтягнути свіжий main, оцінити обсяг розбіжностей і зливати свідомо. Знищення гілки виправдане хіба що в рідкісних випадках безнадійно заплутаної історії, і навіть тоді це крайній захід, а не рефлекс на кожен CONFLICT.

Три кейси з робочого життя AQA, де merge-конфлікт вирішує, згаяли ви хвилину чи півдня: розбір і розвʼязання конфлікту в спільному тестовому конфізі, правильна робота з конфліктом у package-lock.json і таблиця рішень «merge чи abort» плюс перевернуті ours/theirs при rebase. Скрізь — що дивитися й чому.

Кейс 1. Конфлікт у спільному тестовому конфізі: правка → add → commit

Ви оновлюєте свою гілку з автотестами від main і бачите зупинене злиття. Перше — не панікувати, а подивитися, де саме розійшлися рядки:

$ git merge main
Auto-merging tests/support/config.ts
CONFLICT (content): Merge conflict in tests/support/config.ts
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch feature/qa-env
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   tests/support/config.ts

Відкриваємо файл — Git лишив обидві версії між маркерами:

export const LOGIN_TIMEOUT = 5000;

<<<<<<< HEAD
export const BASE_URL = 'https://staging.example.com';
=======
export const BASE_URL = 'https://qa.example.com';
export const RETRIES = 2;
>>>>>>> main

Що дивитися й чому:

• <<<<<<< HEAD — ваша гілка, >>>>>>> main — те, що вливаєте. Між ними, за роздільником =======, два варіанти того самого місця. HEAD тут — ваша feature/qa-env, бо саме в неї ви зливаєте.
• Це не вибір «ліве або праве». Колеги в main не просто змінили BASE_URL, а ще й додали константу RETRIES, якої у вас не було. Механічний «Accept Current» мовчки викине її, і ретраї зникнуть із конфігу — класична тиха втрата чужої потрібної зміни.
• Осмислене рішення — поєднати. Береться новий BASE_URL із main, але зберігається й RETRIES. Фінальний файл без жодного маркера:

export const LOGIN_TIMEOUT = 5000;

export const BASE_URL = 'https://qa.example.com';
export const RETRIES = 2;

Далі — протокол із трьох кроків. Перед комітом окремо переконуємось, що в дереві не лишилося жодного маркера:

$ grep -rnE '^(<<<<<<<|=======|>>>>>>>)' tests/
# порожній вивід — маркерів немає, можна комітити

$ git add tests/support/config.ts   # позначає конфлікт розвʼязаним
$ git status
All conflicts fixed but you are still merging.

$ git commit                        # створює merge-коміт із готовим повідомленням

git add тут має особливий сенс: він не просто кладе файл у staging, а знімає його зі списку «Unmerged paths». Доки хоч один файл лишається невзгодженим, git commit не завершить злиття. Останній коміт — це merge-коміт із двома батьками, що фіксує сам факт зʼєднання гілок.

Кейс 2. Конфлікт у package-lock.json: не мерджити, а перегенерувати

Ваша гілка додала @faker-js/faker, а в main тим часом оновили @playwright/test. Обидві зміни зачепили дерево залежностей — і lock-файл конфліктує на десятках рядків одразу:

$ git merge main
CONFLICT (content): Merge conflict in package.json
CONFLICT (content): Merge conflict in package-lock.json
Automatic merge failed; fix conflicts and then commit the result.

Спокуса відкрити package-lock.json і звести маркери руками — головна помилка. Файл на тисячі рядків фіксує точні версії всього графа залежностей; втримати його в голові неможливо, а ручна правка легко зробить lock неконсистентним із package.json, після чого збірка почне поводитись непередбачувано. Правильний порядок дій:

# 1. Спершу осмислено розвʼязуємо конфлікт у package.json — там рядків мало
$ git status --short
UU package.json
UU package-lock.json
#    (у package.json лишаємо ОБИДВІ нові залежності — і faker, і оновлений playwright)

# 2. Lock не редагуємо — беремо будь-яку сторону, все одно перегенеруємо
$ git checkout --theirs package-lock.json   # або --ours, байдуже

# 3. Даємо менеджеру заново вивести коректний lock із фактичного package.json
$ npm install

# 4. Позначаємо обидва файли розвʼязаними
$ git add package.json package-lock.json
$ git commit

Що дивитися й чому:

• Джерело істини — package.json, а lock лише його похідна. Ви примиряєте зрозумілий список бажаних залежностей, а точні версії дерева менеджер відновлює сам однією командою.
• git checkout --theirs тут безпечний саме тому, що далі npm install. Ми не «обираємо чиюсь версію lock» — ми викидаємо конфліктний lock і генеруємо новий. Деякі версії npm/yarn узагалі зводять конфліктний lock автоматично прямо при install.
• Фінальна перевірка — чисте встановлення. Після коміту варто переконатися, що npm ci на CI не впаде: він ставить рівно за lock і швидко викриє неконсистентність. І, звісно, у lock не має лишитися жодного маркера.

Кейс 3. merge чи abort, і чому rebase перевертає ours/theirs

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

Остання ситуація ховає класичну пастку. При rebase значення --ours і --theirs перевертаються порівняно з merge, бо Git накладає ваші коміти на нову базу й «своєю» вважає базу:

# merge: HEAD — ваша гілка
$ git checkout --ours   file   # лишити СВОЮ версію

# rebase: ours — це база (свіжий main!), theirs — ваш коміт, який накладається
$ git checkout --theirs file   # ось так лишити СВОЮ версію під час rebase

Тому під час rebase не покладайтеся на --ours/--theirs за звичкою — дивіться на фактичний зміст рядків. А сам вибір merge проти rebase у прикладній автоматизації часто вирішується перевіркою на CI: важлива поведінка тесту після злиття, а не краса історії. Простий Playwright-тест-димок після примиреного конфігу дає впевненість, що жодна константа не загубилась при розвʼязанні:

import { test, expect } from '@playwright/test';
import { BASE_URL, RETRIES } from '../support/config';

test('конфіг після злиття цілісний', () => {
  // обидві зміни доїхали: і новий URL із main, і власні ретраї
  expect(BASE_URL).toBe('https://qa.example.com');
  expect(RETRIES).toBe(2);
});

Природа конфлікту

• Розумію, що конфлікт — не поломка Git, а чесна відмова вгадати, чия з двох різних правок того самого місця «правильніша»; Git зіставляє рядки тексту, а не зміст коду, тож логічно сумісні правки сам не поєднує.
• Можу пояснити тристороннє злиття (three-way merge): Git бере вашу гілку, чужу й базу злиття (спільного предка) — і саме база дає критерій: правку однієї сторони він застосовує сам, а розходження обох на тому самому рядку зупиняє.
• Можу пояснити, чому правки в різні ділянки одного файлу зливаються без конфлікту, а надто близькі рядки конфліктують навіть без прямого перетину (Git працює блоками, hunk).

Маркери й розвʼязання

• Читаю маркери: <<<<<<< HEAD — моя версія, ======= — роздільник, >>>>>>> — чужа гілка (або хеш коміту при rebase).
• Розумію, що розвʼязати — прибрати всі три маркери й лишити правильний фінальний текст; часто відповідь поєднує обидва боки (взяти чужий рядок, але зберегти свою нову константу), а не бере один цілком.
• Памʼятаю протокол: правка файлів → git add (позначає конфлікт розвʼязаним) → git commit (створює merge-коміт).
• Можу пояснити особливий сенс git add у конфлікті: він знімає файл зі списку «Unmerged paths», а не лише кладе у staging.
• Знаходжу конфліктні файли через git status («Unmerged paths») і git diff (самі блоки), а перед комітом завжди прогоняю пошук <<<<<<<, =======, >>>>>>>: забутий маркер — синтаксична помилка й червоний білд на CI.
• Розумію, що кнопки редактора «Accept Current / Incoming / Both» лише правлять текст, а відповідальність за коректний результат лишається на мені.

Аварійний вихід і lock-файли

• Знаю різницю git merge --abort vs git reset --hard: перший акуратно скасовує саме злиття, другий грубо скидає стан і може знести незакомічену роботу.
• Памʼятаю, що merge --abort працює лише до коміту злиття; після нього відкочують revert merge-коміту.
• Розумію здоровий сценарій: десяток чужих конфліктів → merge --abort → підтягнути свіжий main → зливати свідомо.
• Знаю, що lock-файли (package-lock.json, yarn.lock, pnpm-lock.yaml) не мерджать руками, а перегенеровують через install: джерело істини — package.json, а lock лише похідна, тож ручна правка робить його неконсистентним і ламає збірку.

Merge проти rebase

• Знаю різницю: merge конфліктує один раз і лишає merge-коміт; rebase — покомітно, з git rebase --continue після кожного, з лінійною історією.
• Памʼятаю, що аварійний вихід відрізняється: git merge --abort проти git rebase --abort.
• Розумію пастку перевернутих --ours/--theirs при rebase: ours стає базою, theirs — вашим комітом, тож не покладаюся на них наосліп.
• Знаю про git rerere (reuse recorded resolution): запамʼятовує розвʼязання й застосовує його повторно, рятує при довгих rebase.

Профілактика

• Розумію, що маленькі короткоживучі PR — це не лише про ревʼю, а й пряма профілактика конфліктів.
• Можу пояснити, чому часта синхронізація з main дешевша: три рядки сьогодні простіше, ніж триста післязавтра.
• Знаю, що автоформатер, поділ власності над файлами й обережність зі спільними config/хелперами/локаторами зменшують площу зіткнення в тестах.