Закомітити — що це, правила оформлення та робота з Git

Що таке коміт у Git

Коміт у Git — це об’єкт, який зберігає стан файлів проєкту на певний момент часу. Кожен коміт містить знімок усіх відстежуваних файлів, посилання на батьківський коміт та метадані. На відміну від інших систем контролю версій, Git використовує content-addressable storage — кожен об’єкт ідентифікується за хешем SHA-1 від його вмісту.

Коли розробник закомітив зміни, Git створює об’єкт коміту, який зберігає: tree об’єкт (структура файлів), хеш батьківського коміту, автор, комітер, дата та повідомлення. Цей об’єкт незмінний — після створення коміт не можна модифікувати без зміни його хеша. Саме незмінність гарантує цілісність історії проєкту.

# Індексувати зміни та зробити коміт
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Переглянути деталі коміту
git log --oneline -3
git show HEAD

# Індексувати всі зміни та зробити коміт одним кроком
git commit -a -m "Update dependencies to latest versions"

Коміти формують спрямований ациклічний граф (DAG), де кожен новий коміт посилається на попередній. Це дозволяє переміщатися історією, скасовувати зміни та аналізувати еволюцію кодової бази. Розуміння структури Git DAG — основа для просунутої роботи з комітами.

Як правильно закомітити зміни

Процес коміту в Git складається з двох етапів: додавання змін до staging area (індекс) та створення коміту. Staging area дозволяє розробнику вибрати, які саме зміни увійдуть до коміту, навіть якщо в робочій директорії змінено багато файлів.

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

Перед тим як закомітити, варто перевірити: чи не залишилося в коді налагоджувального виведення, закоментованих блоків або випадкових змін. Для цього використовується команда git diff --cached, яка показує, що саме увійде до коміту. Додаткова перевірка через git status виводить список файлів у staging area.

• Перевір зміни — git diff --cached показує що увійде до коміту
• Перевір якість — код має проходити лінтер і тести перед комітом
• Напиши повідомлення — зрозумілий опис мети зміни
• Перевір staged — git status підтверджує список файлів

Правила написання повідомлень комітів

Повідомлення коміту — це документація зміни для майбутніх розробників. Хороше повідомлення відповідає на питання: що змінено і чому. Конвенція Conventional Commits (Angular team, 2016) стала стандартом для багатьох проєктів і визначає формат: тип(область): опис.

Хороше повідомлення коміту складається із заголовка (до 50 символів) і тіла (опціонально, до 72 символів на рядок). Заголовок пишеться в наказовому способі: «Add» а не «Added» або «Adds». Capitalization і крапка в кінці заголовка не ставляться — це міжнародна угода Git.

Погане повідомлення: «fix things» або «update» — воно не несе інформації. Через місяць розробник не зможе зрозуміти, що саме було змінено і навіщо. Хороше повідомлення: «fix(payment): handle timeout in stripe callback» — одразу ясно, де і що виправлено.

Часті помилки при комітах

Розробники, особливо початківці, часто роблять типові помилки при комітах. Найпоширеніша — занадто великий коміт, у якому змішані десятки змін. Такий коміт неможливо відкотити частково, а код-рев’ю перетворюється на муку.

Друга за частотою помилка — погане повідомлення коміту. Повідомлення виду «fix», «update», «changes» або «wip» не дають контексту майбутнім розробникам. Через пів року ніхто не згадає, що саме було виправлено. Правило просте: уяви, що через рік ти дивишся історію і намагаєшся знайти конкретну зміну.

Третя помилка — коміт нескомпільованого або неробочого коду. Після коміту код має як мінімум компілюватися. Не зламаний білд — базова вимога до будь-якого коміту в спільну гілку. Для цього перед комітом запускають збірку і тести.

Четверта помилка — коміт з конфіденційними даними. API-ключі, паролі та токени не мають потрапляти в Git-історію. Якщо секрет уже закомічено, його потрібно не просто видалити в новому коміті, а видалити з усієї історії через git filter-branch або BFG Repo-Cleaner.

Просунуті техніки роботи з комітами

Git надає інструменти для управління історією комітів. Один з найкорисніших — git commit --amend, який дозволяє доповнити останній коміт новими змінами або виправити повідомлення. Це зручно, якщо розробник забув включити файл або помилився в повідомленні.

# Виправити повідомлення останнього коміту
git commit --amend -m "fix(auth): correct token validation logic"

# Додати пропущений файл до останнього коміту
git add missed-file.txt
git commit --amend --no-edit

# Інтерактивний rebase для останніх 3 комітів
git rebase -i HEAD~3

Interactive rebase — потужний інструмент для переписування історії. Дозволяє об’єднувати коміти (squash), змінювати повідомлення (reword), міняти порядок (reorder) і видаляти коміти (drop). Однак rebase змінює історію, тому його застосовують тільки до локальних комітів, які ще не були запущені у віддалений репозиторій.

Для скасування комітів існує два підходи. git revert створює новий коміт, який скасовує зміни попереднього — безпечний спосіб, що зберігає історію. git reset видаляє коміти з історії — небезпечний, якщо коміти вже запущені. У командній розробці використовують тільки git revert для скасування опублікованих комітів.