De ce Git

Lectură estimată: 7 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

Problema pe care o vei rezolva: Conflict de Git cu recuperare

Repository de laborator cu README. Branchul main schimbă instrucțiunea de instalare, branchul feature schimbă aceeași linie și adaugă un exemplu. Nu folosi un repository de producție.

Rezultatul urmărit

Creează conflictul, citește ambele intenții și păstrează instrucțiunea corectă plus exemplul. Înregistrează commiturile, apoi exersează recuperarea unui commit pe un branch separat folosind reflog.

Cum recunoști o soluție corectă

Conflictul este rezolvat fără marcaje rămase și fără pierderea exemplului. Commitul recuperat este referit de un branch. Istoricul partajat nu este rescris pentru a simplifica exercițiul.

Parcurge lecțiile în ordine și păstrează exercițiile în registrul descărcabil. Ultima lecție include atelierul de 40 de minute în care combini conceptele și testezi o variație a situației inițiale. Exemplele comerciale sunt fictive; nu reprezintă rezultate ale unor clienți.

Înainte să înveți comenzi, merită să înțelegi ce problemă rezolvă Git. Altfel o să memorezi git add și git commit fără să știi de ce le scrii, iar în prima situație neprevăzută o să rămâi blocat.

Aproape toți oamenii care ajung la Git au trecut întâi prin varianta manuală. Ai un folder cu proiectul, faci o modificare mai mare și, ca să fii sigur că nu strici ce funcționează, copiezi folderul. Așa apar site, site-copie, site-final, site-final-2 și, inevitabil, site-final-ASTA-E-BUNA.

Funcționează până într-o zi. Ziua aceea vine când trebuie să răspunzi la o întrebare simplă: ce s-a schimbat între versiuni și de ce?

Ce este de fapt Git

Git este un sistem de control al versiunilor. În loc să păstrezi copii întregi ale folderului, Git păstrează istoricul modificărilor: cine a schimbat, ce a schimbat, când și — dacă scrii mesaje decente — de ce.

Concret, Git îți dă patru lucruri pe care copierea de foldere nu ți le dă niciodată:

Istoric complet. Poți vedea orice stare prin care a trecut proiectul și te poți întoarce la ea.
Context. Fiecare modificare are autor, dată și mesaj. Peste șase luni, mesajul acela e singurul lucru care îți explică de ce codul arată ciudat.
Lucru în paralel. Poți începe o funcționalitate nouă fără să atingi versiunea care merge în producție.
Colaborare fără să vă călcați pe picioare. Doi oameni pot lucra în același fișier, iar Git știe să combine rezultatul.

Git funcționează local, pe calculatorul tău. Nu ai nevoie de internet și nu ai nevoie de GitHub ca să folosești Git. Asta e o confuzie extrem de des întâlnită la început, așa că hai să o lămurim acum.

Git nu este GitHub

Git este programul care ține istoricul. GitHub este un serviciu online unde poți găzdui repository-uri Git, ca să le ai într-un loc sigur și ca să poată ajunge și alți oameni la ele.

Git e motorul. GitHub e parcarea publică unde îți ții mașina și unde o pot vedea și alții. Poți avea motor fără parcare. Parcarea, fără motor, nu te duce nicăieri.

Alternative la GitHub există: GitLab, Bitbucket, Gitea, Codeberg. Toate vorbesc același Git. Ce înveți aici funcționează la fel peste tot; se schimbă doar interfața web și denumirile unor butoane.

Cele trei zone pe care trebuie să le ai în cap

Dacă reții un singur lucru din lecția asta, reține diagrama următoare. Aproape toate confuziile de început vin din faptul că oamenii nu știu în care zonă se află modificarea lor.

  Working directory  →  Staging area  →  Repository
   (fișierele tale)      (git add)        (git commit)

Working directory — folderul în care editezi. Aici există modificările tale nesalvate în istoric.
Staging area (sau „index") — o zonă intermediară în care pui modificările pe care vrei să le incluzi în următorul commit. Aici e diferența față de alte sisteme: poți alege o parte din ce ai modificat.
Repository — istoricul propriu-zis, folderul ascuns .git. Ce ajunge aici e salvat permanent.

Staging area pare o complicație inutilă la început. Nu e. Ea îți permite să faci ordine: dacă ai reparat un bug și, între timp, ai schimbat și niște spații, poți commite separat bug-ul, ca istoricul să rămână citibil.

Instalare și prima configurare

Pe Windows instalezi Git for Windows, care îți aduce și Git Bash — un terminal în care funcționează comenzile din curs. Pe macOS vine cu Xcode Command Line Tools (xcode-select --install), iar pe Linux îl iei din managerul de pachete (sudo apt install git).

Verifici instalarea:

git --version
# git version 2.47.0

Apoi spui cine ești. Numele și emailul ajung în fiecare commit pe care îl faci, deci pune date reale:

git config --global user.name "Numele Tău"
git config --global user.email "adresa@exemplu.ro"

Mai sunt trei setări care îți scutesc mult timp mai târziu:

# branch-ul principal se va numi main, nu master
git config --global init.defaultBranch main

# editorul folosit pentru mesaje de commit (exemplu: VS Code)
git config --global core.editor "code --wait"

# pe Windows: normalizează sfârșiturile de linie
git config --global core.autocrlf true

Ultima merită explicată. Windows termină liniile cu CRLF, Linux și macOS cu LF. Fără setarea asta, o să vezi diff-uri în care „s-a schimbat tot fișierul", deși nimeni nu a atins nimic. Este una dintre cele mai frecvente frustrări ale începătorilor pe Windows.

Poți verifica oricând ce ai configurat:

git config --list --show-origin

Ce înseamnă un commit bun

Un commit este o fotografie a proiectului la un moment dat, însoțită de un mesaj. Calitatea istoricului tău este dată aproape exclusiv de calitatea acestor mesaje.

Regula practică: mesajul răspunde la întrebarea „ce face acest commit?", la timpul prezent, pe prima linie, în maximum 50-72 de caractere.

# slab
update
fix
modificari
asdf

# bun
Adaugă validare pentru formularul de contact
Repară calculul TVA la produsele cu reducere
Elimină scriptul de analytics neutilizat

Dacă ai nevoie de context suplimentar (de ce ai ales soluția asta, ce alternative ai respins, ce bug reproduce), lași o linie goală și scrii un paragraf după titlu. Nu e birocrație: peste un an, tu vei fi cel care citește.

Cât de des faci commit

Regula bună: un commit = o schimbare logică completă.

Prea rar (un commit pe zi, cu 40 de fișiere) înseamnă că nu mai poți izola nimic și nu poți da înapoi o singură decizie. Prea des (un commit per literă scrisă) înseamnă zgomot în istoric.

Întrebarea de control: dacă mâine trebuie să anulez exact această schimbare, pot să o fac fără să distrug altceva? Dacă răspunsul e da, e un commit bun.

De ce contează asta chiar dacă lucrezi singur

Mulți începători cred că Git e util doar în echipă. Realitatea e că cele mai mari beneficii apar și când lucrezi singur:

poți experimenta fără frică, pentru că întotdeauna te poți întoarce;
poți afla când s-a stricat ceva care funcționa (git log, git bisect);
ai o copie de siguranță reală în momentul în care trimiți pe GitHub;
îți construiești un portofoliu public, dacă repository-urile sunt deschise.

Exercițiu

Instalează Git și rulează git --version.
Configurează user.name, user.email și init.defaultBranch.
Rulează git config --list și verifică valorile.
Scrie pe hârtie trei mesaje de commit pentru ultimele trei modificări pe care le-ai făcut într-un proiect. Verifică dacă respectă regula de mai sus.

Ce urmează

În lecția următoare creăm primul repository și trecem efectiv prin ciclul status → add → commit → log, adică fluxul pe care îl vei repeta de mii de ori de acum încolo.

Aplicație practică

Sarcina

Creează două versiuni ale unui fișier și inspectează diferența.

Rezolvare orientativă și verificare

git diff arată modificarea înainte de commit; git log păstrează istoricul după commit.

Greșeală de evitat

Git nu este backup pentru fișiere ignorate și secrete locale.

Documentație și surse

Pro Git — Git