A face commit — ce este, reguli de formatare și lucrul cu Git

Ce este un commit în Git

Un commit în Git este un obiect care stochează starea fișierelor proiectului la un moment dat. Fiecare commit conține o imagine instantanee a tuturor fișierelor urmărite, o referință la commit-ul părinte și metadate. Spre deosebire de alte sisteme de control al versiunilor, Git folosește content-addressable storage — fiecare obiect este identificat prin hash-ul SHA-1 al conținutului său.

Când dezvoltatorul face commit la modificări, Git creează un commit object care stochează: tree object (structura fișierelor), hash-ul commit-ului părinte, autor, comitter, dată și mesaj. Acest obiect este imuabil — după creare, commit-ul nu poate fi modificat fără schimbarea hash-ului său. Tocmai imuabilitatea garantează integritatea istoricului proiectului.

# Pregătește modificările și fă commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Vezi detaliile commit-ului
git log --oneline -3
git show HEAD

# Pregătește toate modificările și fă commit într-un singur pas
git commit -a -m "Update dependencies to latest versions"

Commiturile formează un graf aciclic direcționat (DAG), unde fiecare commit nou se referă la precedentul. Acest lucru permite deplasarea prin istoric, anularea modificărilor și analiza evoluției bazei de cod. Înțelegerea structurii Git DAG — baza pentru lucrul avansat cu commiturile.

Cum să faci corect commit la modificări

Procesul de commit în Git constă din două etape: adăugarea modificărilor în staging area (index) și crearea commit-ului. Staging area permite dezvoltatorului să selecteze care modificări vor intra în commit, chiar dacă în directorul de lucru s-au modificat multe fișiere.

Regula atomicității — principiul cheie al unui commit bun. Fiecare commit trebuie să conțină o singură modificare logică. Dacă dezvoltatorul corectează un bug și refactorizează codul — sunt două commituri diferite. Commiturile atomice simplifică code review, anularea modificărilor și analiza istoricului.

Înainte de a face commit, merită verificat: dacă au rămas în cod ieșiri de debug, blocuri comentate sau modificări accidentale. Pentru aceasta se folosește comanda git diff --cached, care arată exact ce va intra în commit. Verificarea suplimentară prin git status afișează lista fișierelor din staging area.

• Verifică modificările — git diff --cached arată ce intră în commit
• Verifică calitatea — codul trebuie să treacă de linter și teste înainte de commit
• Scrie mesajul — descrierea clară a scopului modificării
• Verifică staged — git status confirmă lista fișierelor

Reguli pentru scrierea mesajelor de commit

Mesajul commit-ului este documentarea modificării pentru viitorii dezvoltatori. Un mesaj bun răspunde la întrebările: ce a fost modificat și de ce. Convenția Conventional Commits (echipa Angular, 2016) a devenit standard pentru multe proiecte și definește formatul: tip(domeniu): descriere.

Un mesaj de commit bun constă dintr-un titlu (până la 50 de caractere) și un corp (opțional, până la 72 de caractere pe linie). Titlul se scrie la modul imperativ: „Add” nu „Added” sau „Adds”. Capitalizarea și punctul la sfârșitul titlului nu se folosesc — aceasta este convenția internațională Git.

Mesaj prost: „fix things” sau „update” — nu poartă informație. După o lună, dezvoltatorul nu va putea înțelege ce anume a fost modificat și de ce. Mesaj bun: „fix(payment): handle timeout in stripe callback” — imediat clar unde și ce a fost corectat.

Greșeli frecvente la commituri

Dezvoltatorii, în special începătorii, comit adesea greșeli tipice la commituri. Cea mai răspândită — commit prea mare, în care sunt amestecate zeci de modificări. Un astfel de commit nu poate fi anulat parțial, iar code review-ul devine un chin.

A doua greșeală ca frecvență — mesaj prost de commit. Mesajele de tip „fix”, „update”, „changes” sau „wip” nu oferă context viitorilor dezvoltatori. Peste șase luni nimeni nu-și va aminti ce anume a fost corectat. Regula este simplă: imaginează-ți că peste un an te uiți în istoric și încerci să găsești o modificare specifică.

A treia greșeală — commit de cod necompilat sau nefuncțional. După commit, codul trebuie cel puțin să se compileze. Build ne stricat — cerința de bază pentru orice commit într-o ramură comună. Pentru aceasta, înainte de commit se rulează build-ul și testele.

A patra greșeală — commit cu date confidențiale. Chei API, parole și tokenuri nu trebuie să ajungă în istoricul Git. Dacă un secret a fost deja comis, nu este suficient să fie șters într-un commit nou — trebuie șters din întreg istoricul prin git filter-branch sau BFG Repo-Cleaner.

Tehnici avansate de lucru cu commiturile

Git oferă instrumente pentru gestionarea istoricului commiturilor. Unul dintre cele mai utile este git commit --amend, care permite completarea ultimului commit cu modificări noi sau corectarea mesajului. Acest lucru este convenabil dacă dezvoltatorul a uitat să includă un fișier sau a greșit în mesaj.

# Corectează ultimul mesaj de commit
git commit --amend -m "fix(auth): correct token validation logic"

# Adaugă fișierul omis la ultimul commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase interactiv pentru ultimele 3 commituri
git rebase -i HEAD~3

Interactive rebase — un instrument puternic pentru rescrierea istoricului. Permite combinarea commiturilor (squash), schimbarea mesajelor (reword), schimbarea ordinii (reorder) și ștergerea commiturilor (drop). Totuși, rebase modifică istoricul, de aceea se aplică doar commiturilor locale care nu au fost încă trimise în depozitul la distanță.

Pentru anularea commiturilor există două abordări. git revert creează un commit nou care anulează modificările precedentului — o metodă sigură care păstrează istoricul. git reset șterge commiturile din istoric — periculos dacă commiturile au fost deja trimise. În dezvoltarea în echipă se folosește doar git revert pentru anularea commiturilor publicate.