A face push — ce este, cum funcționează git push și când este necesar

Ce este push-ul în Git

Git push este o comandă care transferă commit-urile din depozitul local în cel la distanță. Spre deosebire de commit, care salvează modificările doar pe mașina locală a dezvoltatorului, push publică aceste modificări pentru întreaga echipă. Push este un pas obligatoriu înainte de crearea unui Pull Request și de implementare.

Arhitectura Git presupune că fiecare dezvoltator lucrează în propriul depozit local. Commit-urile sunt create local și se acumulează până când dezvoltatorul decide să le trimită. Acest lucru oferă libertate: se pot face multe commit-uri locale, experimenta și rescrie istoricul fără a afecta colegii.

# Push la origin remote, ramura main
git push origin main

# Trimite ramura curentă la remote cu upstream
git push -u origin feature/new-dashboard

# Trimite toate ramurile cu nume corespunzătoare
git push --all origin

# Force push cu lease (force push sigur)
git push --force-with-lease

După push, depozitul la distanță actualizează refs (referințele către ramuri) astfel încât să indice către noile commit-uri. Alți dezvoltatori pot obține aceste modificări prin git pull sau git fetch. Tocmai acest schimb de commit-uri stă la baza dezvoltării colaborative.

Cum funcționează git push

Comanda git push compară ramurile locale și la distanță și transmite doar commit-urile lipsă. Git nu trimite toate fișierele din nou — transmite doar delta, ceea ce face push-ul rapid chiar și în depozite mari. Protocolul Git folosește smart transfer, care minimizează volumul de date transmise.

Dacă ramura la distanță conține commit-uri care nu există local, push-ul va fi respins. Acesta este un mecanism de protecție care previne pierderea modificărilor. În această situație, dezvoltatorul trebuie mai întâi să execute git pull, să îmbine modificările și abia apoi să facă din nou push. Alternativa este force push, care suprascrie ramura la distanță, dar trebuie folosit cu prudență.

Înțelegerea depozitelor la distanță este cheia unui push corect. De obicei se folosește origin — numele implicit al depozitului la distanță. Comanda git remote -v afișează lista depozitelor la distanță și URL-urile lor. Se pot adăuga mai multe remote (de exemplu, origin pentru depozitul principal și upstream pentru fork).

Când să facem push modificărilor

Regula de bază: trebuie să facem push după fiecare etapă de lucru logic încheiată. Dacă dezvoltatorul a finalizat o sarcină sau o parte din ea — e timpul să facă push. Totuși, a face push pentru o muncă neterminată care strică build-ul nu este recomandat. Build-ul funcțional este cerința minimă pentru a face push în orice ramură.

În dezvoltarea în echipă se adoptă următorul ritm: dimineața — git pull pentru a obține modificările colegilor, pe parcursul zilei — câteva commit-uri și unul sau două push-uri, seara — push-ul final al tuturor sarcinilor finalizate. Cu cât un dezvoltator face push mai des, cu atât riscul de conflicte la îmbinarea ramurilor este mai mic și progresul muncii mai transparent.

• După finalizarea sarcinii — a face commit și a trimite soluția finală în ramura feature
• Înainte de plecare — a trimite munca neterminată în ramura feature (nu în main!)
• Înainte de crearea PR — a se asigura că toate commit-urile sunt trimise și disponibile pentru review
• După rebase — a trimite cu --force-with-lease în propria ramură feature

Reguli pentru un push sigur

Push-ul sigur este un set de reguli care previn pierderea datelor și conflictele în echipă. Prima și cea mai importantă regulă: nu faceți niciodată push direct în ramura main sau master, dacă în proiect nu este configurată o implementare directă. În echipele moderne, protecția ramurii main se configurează la nivel de GitHub branch protection.

A doua regulă: înainte de push, sincronizați-vă cu ramura la distanță. Executați git pull --rebase pentru a evita un commit de îmbinare la combinare. Acest lucru simplifică istoricul și îl face liniar. Dacă push-ul este respins — nu folosiți force push pur, ci mai întâi verificați ce commit-uri au apărut în ramura la distanță.

A treia regulă: configurați hook-uri pre-push care rulează automat testele și linter-ul înainte de trimitere. Dacă testele eșuează — push-ul este blocat. Astfel de hook-uri se configurează prin Husky sau Git hooks (fișierul pre-push în .git/hooks).

A patra regulă: nu faceți push pentru fișiere binare mari. Git nu este conceput pentru stocarea artifactelor binare — ele umflă depozitul și încetinesc operațiile. Pentru fișiere mari se folosește Git LFS (Large File Storage). Dacă un fișier binar a fost deja trimis și a intrat în istoric, trebuie șters prin git filter-branch.

Ce facem dacă push-ul nu reușește

Cea mai frecventă cauză a unui push eșuat — ramura la distanță conține commit-uri care nu există local. Acest lucru se întâmplă când un alt dezvoltator a trimis modificările sale în aceeași ramură. Soluția: executați git pull, rezolvați eventualele conflicte și repetați push-ul.

# Push respins — mai întâi fetch și rebase
git fetch origin
git rebase origin/main
# Rezolvă conflictele, apoi:
git push --force-with-lease

# Sau pur și simplu îmbină modificările la distanță
git pull origin main
git push

A doua cauză — lipsa drepturilor de scriere în ramură. Dacă ramura main este protejată de o regulă branch protection, push-urile directe sunt interzise. Soluția: faceți push în ramura feature și creați un Pull Request. Setările de protecție sunt de obicei administrate prin GitHub settings sau GitLab protected branches.

A treia cauză — probleme de autentificare. Credențiale învechite, trecerea la SSH sau schimbarea token-ului de acces personal. Soluția: verificați URL-ul remote (git remote -v) și actualizați credențialele. Din 2021, GitHub a anulat autentificarea prin parolă pentru HTTPS — se folosește un token personal sau o cheie SSH.