Комитване — какво е това, правила за форматиране и работа с Git

Какво е комит в Git

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

Когато разработчикът комитва промени, Git създава commit обект, който съхранява: 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 позволява на разработчика да избере кои промени да влязат в комита, дори ако в работната директория са променени много файлове.

Правилото за атомарност — ключов принцип за добър комит. Всеки комит трябва да съдържа една логическа промяна. Ако разработчикът поправя бъг и рефакторира кода — това са два различни комита. Атомарните комити опростяват код-ревюто, отмяната на промени и анализа на историята.

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

• Провери промените — git diff --cached показва какво влиза в комита
• Провери качеството — кодът трябва да преминава linter и тестове преди комит
• Напиши съобщение — разбираемо описание на целта на промяната
• Провери staged — git status потвърждава списъка с файлове

Правила за писане на съобщения за комит

Съобщението за комит е документация на промяната за бъдещи разработчици. Доброто съобщение отговаря на въпросите: какво е променено и защо. Конвенцията Conventional Commits (екип на Angular, 2016) се превърна в стандарт за много проекти и определя формата: тип(област): описание.

Доброто съобщение за комит се състои от заглавие (до 50 знака) и тяло (по избор, до 72 знака на ред). Заглавието се пише в повелително наклонение: „Add” а не „Added” или „Adds”. Главна буква и точка в края на заглавието не се използват — това е международното споразумение на 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 за отмяна на публикувани комити.