Git для AQA: bisect, blame, хуки й теги

Що таке git bisect і яку задачу він розвʼязує?

git bisect — це вбудований у git бінарний пошук по історії, який показує, на якому саме коміті щось зламалося. Типова ситуація: тиждень тому автотест був зелений, сьогодні червоний, а між цими станами кількасот комітів. Перебирати їх з кінця по одному — марна витрата годин. Bisect бере від вас один коміт, де перевірка ще проходила (good), і один, де вже падає (bad), ділить проміжок навпіл і чекаутить середину. Ви ганяєте тест, кажете good чи bad — і половина кандидатів відпадає за один прогін. За кілька ітерацій git виводить перший поганий коміт, і замість сотень дифів ви дивитеся рівно в один. Для AQA це головний спосіб не просто завести баг, а вказати, який коміт його породив.

Чому bisect знаходить винуватця за десяток прогонів, а не за двісті?

Бо це поділ навпіл, а не перебір. Лінійна перевірка з кінця в найгіршому разі коштує стільки прогонів, скільки комітів у діапазоні. Бінарний пошук щоразу викидає цілу половину, тому кількість кроків — це логарифм за основою два від кількості комітів: для двохсот виходить близько восьми прогонів, для тисячі — близько десяти. Саме тому інтервʼюер за словом «bisect» одразу слухає, чи розуміє кандидат логарифмічну природу пошуку, — це відрізняє «щось таке чув» від «щодня цим локалізую регресії».

Як зробити, щоб bisect сам ганяв тест, а не ви руками на кожному кроці?

Для цього є git bisect run <команда>: замість того, щоб на кожному кандидаті запускати перевірку вручну й натискати good/bad, ви віддаєте git команду, яка сама виносить вирок. Виглядає це як git bisect start HEAD v2.3.0 (спочатку bad, потім good) і далі git bisect run npx playwright test checkout.spec.ts. Git на кожному кроці чекаутить черговий коміт, запускає вашу команду й читає її код виходу, щоб зрозуміти, добрий коміт чи ні. Playwright і CodeceptJS при фейлі природно віддають ненульовий код, тож обгортка навіть не потрібна. Через кілька хвилин git сам напише, який коміт перший поганий, разом із його дифом. Це перетворює півдня ручного розкопування на одну команду й каву.

Що означають коди виходу для git bisect run?

git bisect run тлумачить результат команди саме за кодом виходу, а не за текстом у консолі. Нуль — коміт добрий (тест пройшов). Код 125 — особливий: «цей коміт неможливо оцінити», тобто його треба пропустити (наприклад, він не збирається). Будь-який інший ненульовий код у діапазоні від 1 до 127, крім 125, означає поганий коміт. Це важливо розуміти, коли пишете власний скрипт-оракул: якщо ваш враппер завжди повертає 1 навіть на «нема сенсу тестувати», git вважатиме такий коміт зламаним і зіпсує пошук. Для нетестованих проміжних комітів правильний код — саме 125 (або ручне git bisect skip).

Чому flaky-тест робить результат bisect недостовірним?

Бо бінарний пошук працює лише на монотонному зламі: має існувати чітка межа, до якої тест стабільно зелений, а після — стабільно червоний. Flaky-тест цю монотонність руйнує: він падає й проходить випадково, незалежно від коду. Якщо на «доброму» боці історії такий тест раптом дасть червоне (чи навпаки), git повірить хибному вироку й відкине не ту половину — і виведе на коміт, який ні до чого не причетний. Тому перед bisect тест-оракул треба зробити детермінованим: прибрати гонки, зайві очікування, залежність від порядку. Спершу стабільний оракул — потім пошук, інакше ви шукаєте винуватця не там.

Що показує git blame і які прапорці варто знати?

git blame відповідає на питання «хто востаннє торкався кожного рядка файлу»: навпроти кожного рядка він ставить коміт, автора й дату. Для AQA це швидкий спосіб зрозуміти, звідки взявся конкретний селектор або коли з тесту зникла перевірка. Корисні прапорці: -L 40,60 звужує вивід до діапазону рядків, -w ігнорує зміни, що торкнулися лише пробілів і відступів, -M простежує рядок крізь його переміщення в межах файлу, а -C — навіть крізь копіювання чи переміщення з інших файлів. Ці прапорці рятують, коли рядок фізично переїхав, але логічно лишився тим самим.

У чому головна пастка git blame і як її обійти?

Пастка в тому, що blame показує останнє торкання рядка, а не причину його появи. Хтось прогнав файл через новий форматер чи автолінтер — і тепер blame на кожному рядку вказує на цей косметичний коміт, ховаючи справжнього автора логіки. Виглядає, ніби «цей коміт зламав усе», а насправді він лише переставив лапки. Проти цього є .git-blame-ignore-revs — версіонований список хешів «шумних» комітів (масові реформати), які blame пропускає, якщо ввімкнути git config blame.ignoreRevsFile .git-blame-ignore-revs. Разом із -w це повертає blame до розмови про зміст, а не про пробіли.

Чим git log -S відрізняється від git log -G?

Обидва шукають не в повідомленнях комітів, а у вмісті дифів, але реагують на різне. -S (його називають pickaxe) спрацьовує, коли в коміті змінилася кількість входжень рядка-підрядка: тобто ловить момент, де фрагмент коду зʼявився або зник. -G показує будь-який коміт, у діфі якого є рядок, що матчить regex, — навіть якщо загальна кількість входжень не змінилась, наприклад рядок просто відредагували на місці. На практиці: -S "getByTestId('pay-btn')" відповідає на «коли цей селектор додали чи прибрали», а -G "getByTestId.*pay" — на «де взагалі чіпали цей патерн». Різниця тонка, і саме тому її люблять як питання на розуміння, а не на зазубрене.

Чим pickaxe (-S) відрізняється від git log --grep?

Це часта плутанина, на якій ловлять. --grep шукає підрядок у тексті повідомлень комітів — тобто в тому, що людина написала в git commit -m. -S (і -G) шукають у самому коді, у вмісті дифів. Якщо треба знайти, у якому коміті додали чи прибрали конкретний виклик функції, --grep безпорадний: він знайде коміт лише якщо автор випадково згадав цей виклик у меседжі. Правильний інструмент для пошуку за вмістом зміни — pickaxe -S або regex -G, а --grep лишіть для випадків «знайди коміт зі словом revert у описі».

Annotated проти lightweight тега — коли який і чому це не косметика?

Тег — це вказівник, назавжди прибитий до конкретного коміту (на відміну від гілки, що їде вперед). Різниця між двома видами тегів суттєва. Lightweight-тег — це фактично закладка: голий ref на коміт, без інформації, хто його поставив, коли й навіщо. Annotated-тег (git tag -a v2.4.1 -m "...") — це окремий git-обʼєкт із метаданими: імʼя таггера, дата, повідомлення, і його можна підписати GPG (-s). Канонічне правило: релізи тегують annotated, бо номер релізу мусить нести контекст і переживати час; lightweight лишають для тимчасових особистих позначок. Для AQA це прямий інструмент traceability: за v2.4.1 з баг-репорту ви миттєво чекаутите точний стан коду, у якому баг живий.

Чому буває «тег є в мене локально, а в GitHub його немає»?

Бо звичайний git push теги не відправляє — на відміну від комітів. Ви створили тег, він лежить у локальному репозиторії, але на remote його нема, поки не запушите явно: git push origin v2.4.1 для одного тега або git push --tags для всіх. Це не баг git і не збій мережі, а забутий крок. Симптом упізнаваний: білд-система чи деплой «не бачать» реліз, хоча в терміналі тег очевидно є. Перше, що варто перевірити в такій ситуації, — чи тег узагалі доїхав на сервер.

Навіщо git describe і що означає рядок v2.4.1-14-gab12cd3?

git describe будує людиночитабельну назву поточного стану, відштовхуючись від найближчого annotated-тега. Рядок v2.4.1-14-gab12cd3 читається так: від тега v2.4.1 зроблено ще 14 комітів, а поточний коміт має скорочений хеш ab12cd3 (літера g попереду — просто позначка «git»). Це пряма відповідь на питання «а яка версія зараз зібралася?». Багато білд-систем зашивають вивід git describe у застосунок, тож на сторінці About чи в API-відповіді видно точний коміт — і в тесті ви можете звірити, ту саму збірку перевіряєте чи ні. Для цього потрібні саме annotated-теги: за lightweight describe за замовчуванням не чіпляється.

Що таке git-хуки і які з них найкорисніші для AQA?

Git-хуки — це скрипти, які git автоматично запускає в певні моменти життєвого циклу. Ідея для тестувальника проста: зловити проблему на машині розробника за секунди, а не в CI за двадцять хвилин, коли червоний пайплайн уже блокує команду, — це shift-left у чистому вигляді. Найкорисніші клієнтські хуки: pre-commit спрацьовує перед створенням коміту, і ненульовий код виходу коміт скасовує — сюди вішають лінтер і форматер на застейджені файли. commit-msg валідує повідомлення коміту, наприклад формат Conventional Commits. pre-push біжить перед відправкою на remote, і туди виносять довші перевірки: typecheck, юніт-тести, іноді швидкий смоук. Правило поділу — швидке в pre-commit, повільніше в pre-push.

Навіщо husky, якщо git уже вміє хуки з коробки?

Бо «голі» git-хуки живуть у теці .git/hooks/, а вона не комітиться: у git немає штатного способу роздати хуки разом із репозиторієм. У підсумку хук є на вашій машині, а в колеги його нема — і гарантія перетворюється на «кому пощастило налаштувати». Husky закриває саме цю дірку: він тримає хуки у версіонованій теці .husky/ у корені репо й підключає їх через core.hooksPath, тож звичайний npm install розкочує однакові хуки всім у команді. Типова звʼязка для тест-репозиторію — husky плюс lint-staged, щоб лінтер біг лише на застейджених файлах, а не на всьому проєкті щоразу.

Навіщо pre-commit хук, якщо є CI, і чи він щось гарантує?

Хук дає швидкий локальний фідбек: ви бачите проблему до пушу, а не через двадцять хвилин у пайплайні. Але — і це те, що відрізняє middle від junior — хук це зручність, а не бар'єр. Будь-хто пройде повз нього прапорцем git commit --no-verify чи git push --no-verify, а на чужому форку хуків може взагалі не бути. Тому справжній інваріант забезпечує сервер: branch protection, обовʼязкові статус-чеки, той самий лінт і ті самі тести в CI, які не обійти локальним прапорцем. Формула коротка: хуки економлять ваш час, гейти в CI гарантують правило. Одне не заміняє інше, і плутати їх — типова помилка на співбесіді.

Що таке семантичний конфлікт і чому «зелений злиток двох зелених гілок» не гарантований?

Семантичний (логічний) конфлікт — це коли дві гілки, кожна зелена в CI окремо, після мержу дають червоний тест, хоча текстового конфлікту git не побачив і маркерів <<<<<<< не було. Код зійшовся синтаксично, а зміст поламався. Класика: гілка A перейменувала метод getUser() на fetchUser() й оновила всі відомі їй виклики; гілка B, відгалужена раніше, додала новий тест, що кличе старий getUser(). Текстово зміни в різних місцях — злиття чисте, але в результаті є виклик методу, якого вже не існує, і воно падає. Кожна гілка була консистентна сама по собі; зламала їх саме комбінація. Висновок для AQA: злиття двох зелених гілок не зобовʼязане бути зеленим, і це треба ловити.

Як діагностувати семантичний конфлікт і як не допускати його процесом?

Діагностика зшиває всю главу в один ланцюжок. git bisect тут виведе на сам merge-коміт як перший поганий — і це коректно, бо винна не одна сторона, а їх злиття. Далі git show <merge> показує, що саме зійшлося, git log -S "getUser" — де зник виклик, який лишився в тесті, а git blame на рядку тесту вкаже гілку-автора застарілого виклику. Три інструменти дають відповідь за хвилини. Профілактика — процесна: вимога «гілка має бути актуальною відносно бази перед мержем» (у GitHub це Require branches to be up to date before merging) або merge queue змушують CI прогнатись саме на результаті злиття, а не на гілці окремо, — і семантичний конфлікт червоніє ще до потрапляння в майстер.

Три кейси, де git перетворює «тест червоний, і незрозуміло чому» на конкретну відповідь: автоматичний bisect, що сам знаходить коміт-винуватця; розбір семантичного конфлікту після мержа, який зшиває bisect, pickaxe і blame в один ланцюжок; і локальний захисний контур husky + lint-staged разом із перевіркою версії білда через git describe. Скрізь — які команди й що дивитися.

Кейс 1. git bisect run: хай git сам знайде винуватця

checkout.spec.ts був зелений на релізі v2.3.0, а на сьогоднішньому HEAD падає. Між ними — понад сотня комітів. Замість ручного перебору віддаємо пошук git-у: він на кожному кандидаті прогонить сам тест і читатиме код виходу.

git bisect start HEAD v2.3.0        # порядок: <bad> <good>
git bisect run npx playwright test checkout.spec.ts

Git чекаутить середній коміт, запускає Playwright, за кодом виходу вирішує good/bad і звужує діапазон. Через кілька прогонів отримуємо приблизно такий фінал:

running npx playwright test checkout.spec.ts
...
ab12cd3f9e is the first bad commit
commit ab12cd3f9e
Author: Ivan Petrenko
Date:   Tue Jun 9 14:20:11 2026 +0300

    refactor: rename pay-btn testid to submit-payment

 1 file changed, 3 insertions(+), 3 deletions(-)
git bisect reset

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

• Порядок аргументів у start — спершу bad, потім good. git bisect start HEAD v2.3.0 означає «поточний HEAD зламаний, v2.3.0 ще робочий». Переплутаєте місцями — git шукатиме винуватця не в тій половині історії.
• run тлумачить результат за кодом виходу, не за текстом. 0 — коміт добрий, 125 — «неможливо оцінити, пропусти» (наприклад, білд посередині не збирається), будь-який інший код 1–127 — поганий. Тому не пишіть у власному враппері exit 1 на випадок «нема сенсу тестувати» — git визнає коміт зламаним і зіпсує пошук; для такого — exit 125.
• Наприкінці не забудьте git bisect reset. Поки bisect активний, ви в «відчепленому» стані на проміжному коміті. reset повертає на вихідний HEAD; git bisect run кличе його сам, а після ручного циклу це на вас.
• Якщо винуватцем виявився merge-коміт — це не збій bisect. Так виглядає семантичний конфлікт (кейс 2): жодна зі сторін окремо тест не ламала, зламало саме злиття.

Передумова, без якої все марно: оракул має бути детермінованим. Якщо checkout.spec.ts флакі, один випадковий зелений прогін відправить git не в ту половину — спершу приберіть флак, потім запускайте bisect.

Кейс 2. Семантичний конфлікт: зелений злиток двох зелених гілок

Дві гілки пройшли CI кожна окремо, їх змержили — і на майстрі впав тест, якого жодна гілка не чіпала. Конфліктних маркерів не було: git не побачив текстового зіткнення. Це семантичний конфлікт — код зійшовся синтаксично, а зміст поламався.

Розкладка типова. Гілка A перейменувала метод і оновила всі відомі їй виклики:

// було
export function getUser(id: string) { /* ... */ }
// стало (гілка A)
export function fetchUser(id: string) { /* ... */ }

Гілка B, відгалужена до цього перейменування, додала новий тест зі старою назвою:

// гілка B, доданий тест
test('user profile loads', async () => {
  const user = await getUser('42');   // методу вже не існує після мержа
  expect(user.name).toBeDefined();
});

Текстово зміни в різних місцях — злиття чисте. Але після мержа в коді є виклик getUser, якого вже нема, і компіляція чи тест падає. Діагностика — три команди глави підряд:

# 1) хто зламав: bisect виводить на сам merge-коміт
git bisect start HEAD v2.4.0
git bisect run npx tsc --noEmit
#    => <merge-hash> is the first bad commit

# 2) що зійшлося в цьому мержі
git show <merge-hash>

# 3) де зник виклик, який лишився в тесті (pickaxe, не --grep!)
git log -S "getUser(" --oneline

# 4) хто автор застарілого рядка в тесті
git blame -w -M tests/profile.spec.ts

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

• bisect коректно вкаже на merge-коміт, і це правильна відповідь. Винна не гілка A й не гілка B, а факт їх злиття — перший поганий коміт саме merge. Не шукайте «справжнього» винуватця серед батьків: його там немає.
• Шукати зниклий виклик треба через -S, а не --grep. --grep порпається в повідомленнях комітів і getUser у коді не знайде. -S "getUser(" показує саме коміт, де кількість входжень цього фрагмента змінилася, — тобто де перейменування прибрало виклик.
• git blame тут відповідає «звідки взявся застарілий виклик у тесті». З прапорцями -w (без шуму пробілів) і -M (крізь переміщення рядка) він вкаже гілку B як автора рядка, що кличе неіснуючий метод.
• Профілактика — процес, не героїзм. Увімкнена вимога Require branches to be up to date before merging або merge queue змусили б CI прогнатись на результаті злиття, і цей тест почервонів би до потрапляння в майстер.

Кейс 3. husky + lint-staged і git describe як оракул версії

Локальний контур ловить проблему за секунди до пушу, а перевірка версії білда рятує від прогону всього сюїта по застарілому фронтенді. Хуки тримаємо у версіонованій теці .husky/, щоб вони приїхали всім через npm install, а не жили тільки на одній машині.

# .husky/pre-commit — швидке, лише на застейджених файлах
npx lint-staged

# .husky/pre-push — довше: типи й швидкий смоук
npx tsc --noEmit && npx playwright test --grep @smoke

lint-staged конфігурують так, щоб лінтер біг не по всьому проєкту, а лише по тому, що йде в коміт:

{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"]
  }
}

Оракул свіжості в тесті — звірити, що ми взагалі на актуальній збірці. Багато білд-систем зашивають вивід git describe у застосунок, тож версію видно в API чи на сторінці About:

import { test, expect } from '@playwright/test';

test('перевіряємо очікувану збірку до основних асертів', async ({ request }) => {
  const res = await request.get('https://app.example.com/api/version');
  const { build } = await res.json();      // напр. "v2.4.1-14-gab12cd3"
  // старий тег у відповіді = деплой не доїхав, далі ганяти сюїт немає сенсу
  expect(build).toMatch(/^v2\.4\.1-/);
});

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

• .husky/ комітиться, .git/hooks/ — ні. Саме тому husky підключає хуки через core.hooksPath до версіонованої теки: npm install розкочує однакові хуки всій команді, а не тільки тому, хто налаштував.
• lint-staged економить хвилини на кожному коміті. Лінт лише застейджених файлів замість усього проєкту — різниця між «pre-commit непомітний» і «pre-commit, який хочеться обійти».
• Хук — не гарантія. Цей самий tsc --noEmit і смоук мають дублюватися в CI за branch protection, бо git commit --no-verify пройде повз .husky/ за секунду. Локальний контур — про швидкість, серверний — про інваріант.
• git describe дає annotated-теги. За lightweight-тегом describe за замовчуванням не чіпляється, тож щоб версія в білді була осмислена (v2.4.1-14-g...), релізи треба тегувати саме annotated і не забувати запушити тег на remote.

git bisect: пошук винуватця

• Можу пояснити, що git bisect — це бінарний пошук по історії, а не перебір, тож коштує близько log2(N) прогонів, а не N.
• Розумію, що git bisect run <команда> автоматизує пошук за кодом виходу тесту, і Playwright/CodeceptJS віддають ненульовий код при фейлі природно.
• Знаю коди виходу для run: 0 — good, 125 — skip (не тестується), решта 1–127 крім 125 — bad.
• Розумію, чому bisect вимагає монотонного зламу й чому flaky-тест дає хибний вирок — спершу детермінований оракул, потім пошук.

blame і pickaxe: хто і навіщо

• Розумію, що git blame показує останнє торкання кожного рядка (коміт, автор, дата), а не причину його появи, і знаю прапорці -w, -M, -C проти шуму.
• Можу пояснити, як .git-blame-ignore-revs ховає «шумні» коміти масових реформатів, щоб blame показував автора логіки.
• Знаю різницю -S vs -G: -S ловить зміну кількості входжень (поява/зникнення рядка), -G — будь-який діф, що матчить regex.
• Можу пояснити, чим -S/-G відрізняються від --grep: перші шукають у вмісті дифу, --grep — лише в тексті повідомлень комітів.

Теги: annotated vs lightweight

• Знаю різницю: lightweight — голий ref-закладка без метаданих; annotated — окремий обʼєкт із таггером, датою, повідомленням і можливістю підпису.
• Можу пояснити, чому релізи тегують annotated, а lightweight лишають для тимчасових особистих позначок.
• Памʼятаю, що теги не пушаться разом із git push — потрібен явний git push origin <tag> або --tags.
• Розумію вивід git describe (v2.4.1-14-gab12cd3) як оракул версії в пайплайні й що він чіпляється саме за annotated-теги.

Хуки й husky: shift-left локально

• Знаю призначення ключових хуків: pre-commit (лінт/формат на застейджених), commit-msg (валідація повідомлення), pre-push (typecheck, юніти, смоук).
• Розумію, чому .git/hooks/ не роздається з репо і як husky через версіоновану .husky/ та core.hooksPath це виправляє.
• Можу пояснити звʼязку husky + lint-staged — перевірка лише застейджених файлів, а не всього проєкту.
• Памʼятаю головне застереження: хук — це зручність, а не бар'єр; його обходять --no-verify, а гарантію дає branch protection у CI.

Alias-и та семантичний конфлікт

• Розумію, що alias у git config знижує поріг використання рідкісних команд, а alias з ! виконує довільний shell.
• Можу пояснити семантичний конфлікт: обидві гілки зелені окремо, злиток червоний, текстового конфлікту не було.
• Знаю, що git bisect у такому разі коректно вкаже на merge-коміт, а не на одну зі сторін.
• Можу назвати профілактику процесом: актуальність гілки до бази (Require branches to be up to date) або merge queue, щоб CI біг на результаті злиття.