Комитовати — шта је то, правила обликовања и рад са 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 омогућава програмеру да изабере које промене ће ући у комит, чак и ако је у радном директоријуму измењено много датотека.

Правило атомарности — кључни принцип доброг комита. Сваки комит треба да садржи једну логичку промену. Ако програмер поправља баг и рефакторише кôд — то су два различита комита. Атомарни комитови поједностављују код-преглед, опозив промена и анализу историје.

Пре комитовања вреди проверити: да ли је у кôду остао отклањајући излаз, коментарисани блокови или случајне промене. За то се користи команда git diff --cached, која показује шта тачно улази у комит. Додатна провера путем git status приказује листу датотека у staging area.

• Провери промене — git diff --cached показује шта улази у комит
• Провери квалитет — кôд треба да пролази линтер и тестове пре комита
• Напиши поруку — разумљив опис циља промене
• Провери staged — git status потврђује листу датотека

Правила писања порука комитова

Порука комита — документација промене за будуће програмере. Добра порука одговара на питања: шта је промењено и зашто. Конвенција Conventional Commits (Angular team, 2016) постала је стандард за многе пројекте и дефинише формат: тип(област): опис.

Добра порука комита састоји се од наслова (до 50 знакова) и тела (опционо, до 72 знака по реду). Наслов се пише у заповедном начину: „Add” а не „Added” или „Adds”. Велико слово и тачка на крају наслова се не стављају — ово је међународни споразум Git-а.

Лоша порука: „fix things” или „update” — не носи информацију. За месец дана програмер неће моћи да разуме шта је тачно измењено и зашто. Добра порука: „fix(payment): handle timeout in stripe callback” — одмах је јасно где и шта је поправљено.

Честе грешке при комитовима

Програмери, посебно почетници, често праве типичне грешке при комитовима. Најчешћа — превелики комит у коме су помешане десетине промена. Такав комит се не може делимично опозвати, а код-преглед постаје мучење.

Друга по учесталости грешка — лоша порука комита. Поруке типа „fix”, „update”, „changes” или „wip” не дају контекст будућим програмерима. За пола године нико неће запамтити шта је тачно поправљено. Правило је једноставно: замисли да за годину дана гледаш историју и покушаваш да пронађеш конкретну промену.

Трећа грешка — комит некомпајлираног или нерадног кôда. Након комита кôд треба бар да се компајлира. Несломљени билд — основни захтев за сваки комит у заједничку грану. За то се пре комита покрећу изградња и тестови.

Четврта грешка — комит са поверљивим подацима. АПИ кључеви, лозинке и токени не треба да доспеју у 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 за опозив објављених комитова.