Rebazare: ce este, cum funcționează rebase și lucrul cu Git

Ce este rebase în Git

Rebase — este o comandă Git care re-bazează ramura curentă pe ramura specificată: ia toate commit-urile ramurii curente, le salvează temporar, mută indicatorul ramurii pe commit-ul țintă și aplică secvențial commit-urile salvate deasupra lui. Rezultatul — istoria arată ca și cum dezvoltatorul ar fi lucrat direct de la ultimul commit al ramurii țintă.

Sintaxa de bază: git rebase main — aflându-vă în ramura feature, această comandă mută toate commit-urile feature în vârful lui main. Git utilizează strategia three-way merge pentru fiecare commit în parte. Dacă commit-ul A este deja prezent în ramura țintă (determinat prin hash), Git îl omite automat, ceea ce evită duplicarea modificărilor.

Rebase suportă și modul onto pentru mutarea unei părți din commit-uri: git rebase --onto target start end — această formă permite extragerea unui interval de commit-uri dintr-o ramură și aplicarea lor deasupra alteia. De exemplu, git rebase --onto main feature~3 feature va muta ultimele trei commit-uri ale ramurii feature în vârful lui main.

# Treceți la ramura feature
git checkout feature

# Rebazați feature pe main
git rebase main

# După rebase reușit — istoria este liniară
git log --oneline --graph

# Mutați ultimele 3 commit-uri în main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: diferențe cheie

Rebase și merge rezolvă aceeași sarcină — combinarea modificărilor din ramuri diferite — dar o fac în moduri fundamental diferite. Merge păstrează istoria completă a îmbinărilor, creând un merge-commit cu doi părinți. Rebase rescrie istoria, făcând-o liniară. Alegerea între ele depinde de fluxul de lucru al echipei și de regulile de lucru cu depozitul.

Diferența principală — cum este înregistrat faptul îmbinării. Merge păstrează: „în acest punct am îmbinat feature în main” — este informativ pentru istoria proiectului, dar aglomerează jurnalul la îmbinări frecvente. Rebase arată: „commit-urile feature au fost făcute secvențial de la ultima stare a lui main” — este curat, dar ascunde faptul că dezvoltarea a fost paralelă.

A doua diferență — gestionarea conflictelor. La merge, conflictele se rezolvă o singură dată, iar soluția se fixează în merge-commit. La rebase, conflictele pot apărea pentru fiecare commit mutat și fiecare necesită o rezolvare separată. Este mai laborios, dar permite un control mai precis asupra modificărilor care ajung în versiunea finală.

Rebase interactiv: comenzi și flag-uri

Rebase interactiv (git rebase -i) — este modul în care Git deschide un editor cu lista de commit-uri și acțiunile disponibile pentru fiecare dintre ele. Dezvoltatorul poate rescrie istoria înainte de a trimite în depozitul la distanță. Acesta este instrumentul principal pentru menținerea curățeniei commit-urilor în ramura feature.

Comenzile disponibile în modul interactiv: pick (lasă commit-ul așa cum este), reword (schimbă mesajul commit-ului), edit (oprește-te pentru modificări), squash (combină cu commit-ul anterior, păstrând ambele mesaje), fixup (combină, eliminând mesajul), drop (șterge commit-ul). Fiecare comandă se indică în fața hash-ului commit-ului în editorul deschis.

Squash și fixup — comenzile cele mai frecvent utilizate pentru combinarea commit-urilor. Dacă dezvoltatorul a făcut 5 commit-uri mici cu corecturi în timpul lucrului, squash le va combina într-un singur commit logic cu un mesaj semnificativ. Fixup este util pentru corectarea greșelilor de tipar: modificările ajung în commit-ul anterior fără a-și salva propriul mesaj.

# Deschideți editorul pentru ultimele 4 commit-uri
git rebase -i HEAD~4

# Editorul va arăta:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# După salvare — Git execută rebase
# și deschide editorul pentru mesajul commit-ului îmbinat

# Auto-squash fără a deschide editorul
git rebase -i HEAD~4 --autosquash

Flag-ul --autosquash setează automat fixup/squash pentru commit-urile ale căror mesaje încep cu fixup! sau squash!. Accelerează lucrul dacă dezvoltatorul marchează din timp commit-urile pentru combinarea ulterioară. Flag-ul --committer-date-is-author-date păstrează data originală a commit-ului la re-bazare — util pentru păstrarea cronologiei în istorie.

Rezolvarea conflictelor la rebase

Conflictele la rebase apar atunci când Git nu poate aplica automat commit-ul mutat din cauza contradicțiilor cu modificările din ramura țintă. Spre deosebire de merge, unde conflictul se rezolvă o dată, la rebase fiecare commit poate provoca un conflict și trebuie rezolvat secvențial pentru fiecare commit de la cel mai vechi la cel mai nou.

Când apare un conflict, Git suspendă rebase-ul și raportează care commit a cauzat problema. Dezvoltatorul deschide fișierul în conflict (Git marchează zonele conflictuale cu markerii <<<<<<<, =======, >>>>>>>), îl editează, îl adaugă în index (git add) și continuă rebase-ul cu comanda git rebase --continue. Dacă nu se găsește o soluție — git rebase --abort anulează complet re-bazarea.

Sfat: la conflicte multiple, este mai eficient să folosiți git mergetool, care deschide un editor vizual pentru rezolvarea contradicțiilor. De asemenea, puteți omite commit-ul problemă (git rebase --skip), dar acest lucru va șterge modificările sale din istoria finală, ceea ce rareori este soluția corectă.

# Începeți rebase cu conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (conținut): Conflict de îmbinare în file.txt

# Verificați starea
git status
# ambele modificate: file.txt

# Editați secțiunile conflictuale → git add → continuați
git add file.txt
git rebase --continue

# În caz de îndoială — anulați
git rebase --abort

Când nu trebuie făcut rebase

Regula de aur a rebase: nu re-bazați niciodată commit-urile care au fost deja trimise în depozitul la distanță și sunt disponibile altor developeri. Deoarece rebase rescrie hash-urile commit-urilor, colegii vor întâmpina conflicte la încercarea de sincronizare — istoria lor locală va fi în contradicție cu cea rescrisă de la distanță.

Situația în care rebase este categoric interzis: dacă cineva a creat deja o ramură pe baza commit-urilor dvs. (de exemplu, colegul dvs. a făcut o ramură feature din feature-ul dvs.), modificarea istoriei va strica munca lui. În astfel de cazuri trebuie folosit merge. De asemenea, nu se recomandă să faceți rebase chiar înainte de termenul limită — o eroare la rezolvarea conflictelor poate dura mai mult decât s-a anticipat și poate bloca lansarea.

Excepție: dacă ramura este folosită doar de un singur dezvoltator (ramură feature personală, nepublicată sau publicată în modul draft), rebase-ul înainte de push este o practică standard. După publicare și începerea lucrului colectiv — doar merge. GitHub și GitLab oferă implicit squash merge ca un compromis: combină commit-urile într-unul singur, dar nu rescrie istoria ramurii țintă.

• Ramuri publice (main, develop, release) — rebase complet interzis.
• Commit-uri străine — dacă ramura conține commit-uri ale altui dezvoltator, rebase este inadmisibil.
• Înainte de lansare — riscul de conflicte este mai mare: merge este mai sigur cu o zi înainte de termen.
• Ramuri cu tag-uri — mutarea unui commit cu tag încalcă convențiile de versionare semantică.
• CI/CD legat de hash-uri — unele sisteme de deploy identifică build-urile după hash-ul commit-ului; rebase va strica urmărirea.

Flux de lucru practic cu rebase

În echipele moderne, cel mai des se utilizează fluxul de lucru orientat pe rebase în combinație cu GitHub Flow. Procesul arată astfel: dezvoltatorul creează o ramură feature din main, lucrează în ea, se sincronizează periodic prin git rebase main, iar înainte de a crea un pull request efectuează un rebase interactiv pentru curățarea istoriei.

După crearea PR (dacă este necesar să aducă modificări noi din main) se folosește git pull --rebase main în loc de git pull obișnuit. Acest lucru permite aducerea modificărilor fără a crea un merge-commit inutil. Git pull cu flag-ul --rebase este echivalent cu git fetch + git rebase — Git mai întâi încarcă commit-urile noi, apoi re-bazează modificările locale deasupra lor.

Git permite setarea rebase ca comportament implicit pentru pull: git config --global pull.rebase true. După această configurare, git pull execută întotdeauna rebase în loc de merge. Dacă este necesar un pull obișnuit — se folosește git pull --no-rebase. Multe echipe activează și autostash: git config --global rebase.autoStash true — acesta ascunde automat modificările necomitite înainte de rebase și le restaurează după.