Rebase: ce este, cu ce se deosebește de Merge și principiul de funcționare

Ce este Rebase?

Rebase (rebazare) — este o operațiune Git care mută commit-urile din ramura curentă pe un nou punct de referință (bază). În loc să creeze un commit de îmbinare, rebase ia fiecare commit din ramura sursă și îl aplică pe rând peste noua bază. Rezultatul este o secvență liniară de commit-uri fără ramificații.

Numele rebase provine de la „re-base" — schimbarea bazei. Dacă merge unește două ramuri într-un punct, rebase mută de fapt întreaga ramură într-un loc nou, creând iluzia că ați început dezvoltarea de la starea actuală a ramurii țintă. Acest lucru creează o aparență de muncă perfect secvențială.

Conform Atlassian, 2025, echipele care folosesc rebase pentru ramurile feature petrec cu 30% mai puțin timp analizând istoricul commit-urilor comparativ cu echipele care folosesc exclusiv merge. Istoricul liniar simplifică git blame, bisect și vizualizarea jurnalului prin git log --oneline.

Diferența fundamentală față de Merge

Merge unește ramurile creând un commit cu doi părinți. Rebase rescrie istoricul: commit-urile noi sunt create din nou cu hash-uri noi, deși modificările din ele sunt identice cu cele originale. Aceasta înseamnă că rebase schimbă identificatorii SHA ai commit-urilor, ceea ce este critic pentru ramurile publice.

Cum funcționează Rebase

Mecanismul rebase constă din patru pași: Git determină strămoșul comun (merge base) al ramurii curente și țintă, apoi aplică secvențial fiecare commit al ramurii curente peste ramura țintă. Dacă la un pas apare un conflict — rebase se oprește și așteaptă rezolvarea.

# Situația inițială: feature a rămas în urmă față de develop cu 3 commit-uri
git checkout feature/new-login
git rebase develop

# Git ia 3 commit-uri din feature și le aplică peste develop
# Dacă nu există conflicte — rebase se finalizează automat
# Dacă există — Git se oprește la commit-ul conflictual

După rebase, ramura feature conține toate commit-urile din develop plus propriile sale commit-uri, care arată ca o continuare a develop. Acest lucru permite îmbinarea în develop prin fast-forward, fără a crea un commit de îmbinare.

Procesul pas cu pas

Să analizăm un exemplu detaliat: un dezvoltator a creat o ramură feature din develop, a făcut două commit-uri, iar între timp alți dezvoltatori au adăugat trei commit-uri în develop. Rebase va muta cele două commit-uri feature într-un loc nou, creând copii cu SHA noi.

# 1. Creați ramura feature
git checkout -b feature/payment-refactor develop

# 2. Faceți commit-uri în feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Actualizați develop (munca colegilor)
git checkout develop
git pull

# 4. Rebazați feature peste noul develop
git checkout feature/payment-refactor
git rebase develop

# 5. Acum feature poate fi îmbinat prin fast-forward
git checkout develop
git merge feature/payment-refactor

Dacă la pasul 4 apare un conflict, Git se oprește la commit-ul problemă. Dezvoltatorul rezolvă conflictul, face git add și execută git rebase --continue. Dacă trebuie să sară peste un commit — git rebase --skip, dacă să anuleze tot rebase-ul — git rebase --abort.

Omisiunea automată a commit-urilor goale

Indicatorul --empty controlează comportamentul rebase la commit-urile goale — situațiile în care toate modificările commit-ului sunt deja prezente în ramura țintă. Implicit, rebase se oprește și solicită o decizie. Cu indicatorul --empty=drop, Git omite automat astfel de commit-uri fără oprire, ceea ce accelerează rebazarea în masă cu un număr mare de commit-uri.

Rebase interactiv

Interactive rebase (git rebase -i) — un instrument puternic pentru editarea istoricului commit-urilor. Acesta deschide un editor cu lista commit-urilor și comenzile cheie: pick (păstrează), reword (schimbă mesajul), edit (schimbă conținutul), squash (combină cu precedentul), fixup (combină fără mesaj), drop (șterge).

# Rebase interactiv al ultimelor 4 commit-uri
git rebase -i HEAD~4

# În editor se va deschide planul rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Schimbăm în:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Rezultatul: trei commit-uri (ecran de autentificare, validare, aspect) sunt comprimate într-unul singur, iar commit-ul cu comentarii este șters. Acest lucru permite prezentarea unui istoric curat fără ciorne și corecturi pentru review de cod. Interactive rebase este instrumentul standard de pregătire a ramurii feature înainte de Pull Request.

Rebase vs Merge: comparație

Rebase și Merge rezolvă aceeași sarcină — integrarea modificărilor — dar prin metode fundamental diferite. Alegerea între ele depinde de ce istoric doriți să vedeți în git log și cine mai lucrează cu ramura dumneavoastră.

Regula practică: folosiți merge pentru integrarea în ramurile comune (develop, main) și rebase pentru actualizarea ramurilor personale feature la starea curentă. Multe echipe combină: rebase feature pe develop, apoi --no-ff merge în develop.

Influența asupra git bisect

Git bisect — un instrument pentru găsirea commit-ului care a introdus o regresie. La utilizarea merge, git bisect trece corect prin commit-urile de îmbinare, luând în considerare ambii părinți. La rebase, bisect funcționează mai rapid deoarece istoricul este liniar și nu necesită ramificare. Totuși, dacă rebase a fost făcut după ce commit-urile au devenit cunoscute echipei, SHA-urile originale se pierd și bisect poate să nu găsească commit-ul problemă.

Când să aplicați Rebase

Rebase este optim în trei scenarii: pregătirea ramurii feature pentru Pull Request, actualizarea ramurii personale la starea curentă a main/develop și curățarea istoricului înainte de îmbinare. În fiecare caz, rebase îmbunătățește lizibilitatea istoricului fără risc pentru munca în echipă.

Înainte de Pull Request se recomandă efectuarea unui interactive rebase pentru a combina commit-urile de lucru (WIP, corecturi după review) în unități logice semnificative. Acest lucru ușurează review-ul de cod: reviewerul vede nu 15 commit-uri mici, ci 3-5 modificări structurate cu mesaje clare.

Pentru actualizarea ramurii feature, rebase este preferabil merge deoarece nu creează commit-uri de îmbinare suplimentare. Dacă faceți periodic git rebase develop în ramura feature, după îmbinarea finală nu va exista o cascadă de 10 commit-uri de îmbinare — doar commit-uri curate ale funcției peste develop.

Curățarea istoricului prin interactive rebase înainte de îmbinare permite ascunderea corecturilor minore (greșeli de tastare, formatare) și gruparea commit-urilor pe funcționalitate. Mesajele Git trebuie să urmeze convenția Conventional Commits (fix:, feat:, refactor:, docs:), care generează un changelog automat.

Riscuri și reguli Rebase

Rebase — o operațiune periculoasă dacă este aplicată incorect. Riscul principal — rescrierea istoricului publicat. Dacă un dezvoltator face rebase unei ramuri pe care alții au împins-o deja și o folosesc, copiile lor locale se desincronizează și vor trebui să efectueze un force-pull cu riscul de pierdere a datelor.

• Regula de aur: nu faceți niciodată rebase commit-urilor care există deja în depozitul comun. Aceasta se aplică oricăror ramuri la care au acces alți membri ai echipei
• Force push: după rebase-ul ramurii locale feature, este necesar push cu indicatorul --force-with-lease, care este mai sigur decât --force deoarece verifică dacă cineva a actualizat ramura pe server
• Pierderea contextului: rebase distruge informația despre când și din ce ramură a fost creată ramura feature. Dacă este important să păstrați datele de creare a ramurii — folosiți merge
• Conflicte: la rebase, conflictele trebuie rezolvate pentru fiecare commit în parte, ceea ce poate fi obositor la un număr mare de commit-uri

Pentru minimizarea riscurilor, respectați regula: rebase doar pentru ramuri personale care nu au fost publicate. Dacă ramura este deja în depozitul comun — folosiți merge cu --no-ff. La necesitatea rebase-ului unei ramuri publicate — avertizați echipa și coordonați force push în avans.

Protecția automată împotriva rebase-ului periculos se realizează prin server-side hooks: pre-receive hook pe partea serverului Git poate verifica dacă push-ul rescrie commit-uri publicate. GitHub și GitLab oferă protecție încorporată pentru ramurile protejate — force push este blocat dacă protecția nu este dezactivată de administrator.