Branch-uri

Lectură estimată: 4 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.

Branch-urile sunt motivul pentru care Git a câștigat în fața sistemelor mai vechi. În alte sisteme, o ramură era o operațiune grea, care dura minute și pe care o evitai. În Git, un branch este atât de ieftin încât poți face unul pentru o idee pe care o testezi zece minute.

Ce este, de fapt, un branch

Un branch în Git nu este o copie a proiectului. Este doar un indicator care arată către un commit. Când faci un commit nou, indicatorul se mută automat pe el.

A---B---C   (main)
         \
          D---E   (functionalitate-noua)

Mai există un indicator special: HEAD, care arată către branch-ul pe care te afli acum. De aceea în git log vezi HEAD -> main.

Fiindcă un branch e doar un pointer, crearea lui e instantanee, indiferent cât de mare e proiectul.

Comenzile de bază

# vezi branch-urile locale
git branch

# creezi un branch nou
git branch functionalitate-noua

# te muți pe el
git switch functionalitate-noua

# creezi și te muți dintr-o mișcare
git switch -c functionalitate-noua

Probabil ai văzut prin tutoriale git checkout -b. Face același lucru. git checkout este comanda veche, care făcea prea multe lucruri diferite (schimba branch-uri, dar și restaura fișiere), așa că Git a împărțit-o în două comenzi mai clare:

git switch — pentru schimbat branch-uri;
git restore — pentru restaurat fișiere.

Ambele funcționează; în curs folosim variantele noi, mai greu de confundat.

Cum numești branch-urile

Folosește un prefix și o descriere scurtă cu cratime:

feature/export-facturi-pdf
fix/calcul-tva-reducere
chore/actualizare-dependinte
docs/ghid-instalare

Numele contează în echipă: când sunt 30 de branch-uri deschise, „test2" și „andrei-final" nu spun nimic nimănui.

Fluxul normal de lucru

Regula practică într-un proiect sănătos: nu lucrezi niciodată direct pe main. main rămâne versiunea care funcționează.

# pleci mereu de la un main actualizat
git switch main
git pull

# deschizi un branch pentru sarcina ta
git switch -c feature/export-facturi-pdf

# lucrezi normal: editezi, add, commit (de mai multe ori)
git add .
git commit -m "Adaugă generarea PDF pentru facturi"

# publici branch-ul pe remote
git push -u origin feature/export-facturi-pdf

Ce se întâmplă cu fișierele când schimbi branch-ul

Când faci git switch, Git rescrie fișierele din folderul tău ca să reflecte starea branch-ului respectiv. Asta surprinde mulți începători: fișierele „dispar" sau „se schimbă singure". Nu e magie, e exact ce ai cerut.

Dacă ai modificări necommise care intră în conflict cu branch-ul destinație, Git refuză să te mute și îți spune de ce. Ai trei opțiuni:

commiți modificările;
le arunci, dacă nu îți trebuie: git restore .;
le pui deoparte temporar cu git stash.

git stash — pauza salvatoare

Scenariu tipic: ești în mijlocul unei funcționalități și cineva îți cere urgent o reparație în producție.

# pui deoparte tot ce ai nesalvat
git stash push -m "export pdf, in lucru"

# rezolvi urgența
git switch main
git switch -c fix/eroare-500-checkout
# ... repari, commiți, push ...

# te întorci și îți iei lucrul înapoi
git switch feature/export-facturi-pdf
git stash pop

Comenzi utile: git stash list (ce ai pus deoparte), git stash show -p (ce conține), git stash drop (arunci un stash).

Atenție: implicit, git stash nu include fișierele untracked. Pentru ele folosești git stash -u. E o sursă frecventă de „mi-am pierdut fișierul nou".

Branch-uri locale vs. remote

Branch-urile de pe server sunt separate de cele locale. Când rulezi git fetch, Git aduce informația despre ele fără să îți schimbe fișierele:

git fetch
git branch -a        # toate branch-urile, inclusiv cele remote
git switch feature/ceva-facut-de-coleg   # Git creează automat branch local legat de origin

Diferența dintre fetch și pull: fetch doar aduce informația, pull aduce și integrează (fetch + merge). Când vrei să vezi ce s-a schimbat înainte să integrezi, folosești fetch.

Ce ai în branch și nu ai în main

Înainte să deschizi un pull request sau să faci merge, merită să vezi exact ce aduci. Trei comenzi îți răspund la asta:

# commit-urile din branch care nu sunt în main
git log main..feature/export-facturi --oneline

# fișierele modificate față de main
git diff main --stat

# ce e în main și îți lipsește ție
git log feature/export-facturi..main --oneline

Notația cu două puncte se citește „de la … până la". main..branch înseamnă „ce are branch-ul în plus față de main". Inversând ordinea, afli dacă ai rămas în urmă și trebuie să te sincronizezi.

O verificare rapidă a branch-urilor deja integrate, utilă la curățenie:

git branch --merged main      # se pot șterge în siguranță
git branch --no-merged main   # mai au muncă neintegrată

Un scenariu real, cap-coadă

Ești la lucru și primești două sarcini: o funcționalitate nouă și, la mijlocul ei, un bug urgent în producție. Așa arată traseul complet:

git switch main && git pull
git switch -c feature/filtru-comenzi
# ... lucrezi, două commit-uri ...

# apare urgența
git stash push -u -m "filtru comenzi, la jumatate"
git switch main && git pull
git switch -c fix/total-comanda-gresit
# ... repari, commiți, push, pull request ...

# te întorci la ce făceai
git switch feature/filtru-comenzi
git stash pop

# aduci în branch reparația care între timp a intrat în main
git fetch origin
git merge origin/main

Observă ultimul pas: după ce reparația a ajuns în main, o aduci și în branch-ul tău. Altfel lucrezi peste un cod pe care știi deja că îl vei suprascrie la merge.

Curățenie

După ce un branch a fost integrat, îl ștergi ca să nu se adune:

# local
git branch -d feature/export-facturi-pdf

# remote
git push origin --delete feature/export-facturi-pdf

# ștergi referințele locale către branch-uri care nu mai există pe server
git fetch --prune

-d refuză să șteargă un branch neintegrat — e o plasă de siguranță. -D forțează ștergerea; folosește-l doar când ești sigur.

Exercițiu

În repository-ul de test, creează branch-ul feature/pagina-contact și adaugă acolo un fișier nou, cu două commit-uri.
Întoarce-te pe main și verifică: fișierul nu trebuie să existe.
Modifică ceva pe main fără să commiți, apoi încearcă git switch. Rezolvă situația folosind git stash.
Publică branch-ul pe GitHub și verifică-l în interfața web.

Aplicație practică

Sarcina

Creează un branch pentru schimbarea unei pagini.

Rezolvare orientativă și verificare

Fă commit pe branch și revino pe ramura principală. Verifică că modificarea nu apare până la integrare.

Greșeală de evitat

Lucrul necomis poate fi transportat între branch-uri în anumite situații.

Documentație și surse

Pro Git — Git