Git 2.54: як винести hooks у конфіг і правити історію без важкого interactive rebase

Git 2.54 прибрав дві дрібні, але дратівливі речі

Git 2.54 не намагається перевинайти version control. Але він забирає дві рутинні болячки: розкидані hooks по .git/hooks і важку ручну возню з rebase -i, коли треба лише підправити один коміт.

Якщо у тебе в команді є спільні перевірки перед комітом або дрібні правки історії, ця версія справді економить час. Не “вау, новий Git”, а “нарешті менше танців”.

Що саме змінилося

Перший шматок новизни — config-based hooks. Тепер hook можна описати у конфігу Git, а не тільки класти shell-скрипт у .git/hooks. Це означає, що один і той самий скрипт можна підключити до кількох репозиторіїв, кількох подій і навіть розкочувати через system або global config.

Другий шматок — git history. Це новий експериментальний спосіб правити історію для точкових задач: змінити повідомлення коміту або розділити коміт на два. Він не намагається замінити весь interactive rebase, а лише прибирає частину дрібної рутини.

Як винести hooks у конфіг

Починати варто з найпростішого. Наприклад, у тебе є lint-скрипт, який перевіряє код перед комітом і перед push. Раніше це був окремий файл у .git/hooks або якийсь wrapper у репозиторії. У Git 2.54 можна записати це прямо в конфіг:

git config set hook.lint.command ~/.local/bin/lint.sh
git config set --append hook.lint.event pre-commit
git config set --append hook.lint.event pre-push

git config set hook.secret-scan.command ~/.local/bin/secret-scan.sh
git config set --append hook.secret-scan.event pre-commit

Що тут важливо:

• один friendly name може мати кілька подій;
• кілька hooks можуть слухати ту саму подію;
• Git запускає їх у порядку, в якому бачить конфіг;
• якщо треба тимчасово вимкнути hook у конкретному репозиторії, просто приберіть або скиньте його записи hook.<friendly-name>.event у цьому репозиторії.

Практично це корисно там, де команда тримає спільні правила, але не хоче копіювати однакові скрипти в кожен репозиторій вручну. Менше дублювання, менше “ой, у цьому проєкті hook ще старий”.

Де це особливо добре працює

• pre-commit для форматера або linter;
• pre-push для легкого secret scan;
• commit-msg для перевірки шаблону повідомлення коміту.

Коли я б не поспішав

Якщо hook робить складну підготовку середовища, тягне багато залежностей або сильно залежить від локального layout проєкту, класичний .git/hooks ще може бути простіший. Config-based hooks гарні для спільних, передбачуваних задач, а не для маленького локального фетиша з 200 рядків shell-акробатики.

Як правити історію через git history

git history — це вже не про автоматизацію, а про точкову хірургію. У нього є дві базові операції:

• reword, щоб змінити повідомлення коміту;
• split, щоб розбити один коміт на два.

Приклад:

git history reword 9c1f2ab
git history split HEAD -- src/app.ts

Є ще два моменти, які варто запам’ятати.

По-перше, команду позначено як експериментальну. Це не просто формальність, а прямий сигнал: поведінка може змінитися.

По-друге, git history не запускає hooks і не любить merge history. Ще він може працювати в bare repository, бо йому не треба чіпати index або worktree. Тобто це не інструмент для всіх гілок і всіх випадків. Його сила в тому, що він простіший за interactive rebase, коли треба швидко підправити один коміт або розділити великий на два менші.

Коли git history зручніший за rebase -i

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

Коли краще лишити interactive rebase

• у history є merge-коміти;
• треба розрулити конфлікти;
• треба переписати багато комітів одразу;
• потрібен повний контроль над порядком кроків.

Для таких сценаріїв rebase -i усе ще чесніший інструмент. Він складніший, зате зрозуміліший, коли історія вже не така акуратна.

Що точно не робити

• Не вмикай hooks у конфігу наосліп для всіх репозиторіїв без тесту. Якщо hook повільний, усі почнуть лаятися на коміт.
• Не чекай, що git history замінить rebase -i повністю. Не замінить.
• Не використовуй git history на merge-heavy історії, там він просто не для цього.
• Не сприймай відсутність hooks у git history як баг. Це свідоме обмеження, щоб команда не стала stateful хаосом.
• Не переписуй спільну гілку без домовленості з командою. Git тут не винен, але день зіпсує якісно.

Простий rollout-план

1. Онови Git до 2.54+ на одній тестовій машині.
2. Перенеси один простий hook у конфіг.
3. Перевір, що він спрацьовує там, де треба, і не заважає розробникам.
4. Спробуй git history reword на локальній копії історії.
5. Якщо все виглядає нормально, додай коротку командну нотатку, щоб ніхто не шукав нову магію по старих гідах.

Висновок

Git 2.54 не робить життя магічним, але прибирає кілька зайвих ручних рухів. Config-based hooks краще підходять для спільних правил, а git history зручний для точкових правок без важкого rebase -i.

Мій практичний висновок простий, спочатку перенеси один hook у конфіг, потім спробуй одну безпечну правку історії, і тільки після цього вирішуй, чи варто розкочувати новий workflow на всю команду.