Git rebase: tot ce trebuie să știți

Comanda Git rebase combină două ramuri de cod sursă într-una singură. Comanda de merge Git face și asta. Vă explicăm ce face rebase , cum este folosit și când să folosiți merge .

Explozia Git

Frustrat de alte sisteme de control al versiunilor și de actualizările și angajamentele lor lente, Linus Torvalds, celebru pentru kernel-ul Linux, a pus deoparte o lună în 2005 pentru a-și scrie propria lui. L-a numit Git.

Site-uri precum GitHub, GitLab și BitBucket au promovat simbiotic și au beneficiat de Git. Astăzi, Git este utilizat la nivel global, cu 98% din 71 de mii de respondenți într-un sondaj din 2022, folosind Git ca sistem de control al versiunilor.

Una dintre principalele decizii de proiectare ale lui Git a fost viteza. În special, lucrul cu filialele trebuia să fie cât mai rapid posibil. Ramurile sunt o parte fundamentală a sistemelor de control al versiunilor. Un depozit de proiect va avea o ramură principală sau principală. Aici se află baza de cod a proiectului. Dezvoltarea, cum ar fi noile caracteristici, are loc în ramuri laterale separate. Acest lucru împiedică munca depusă în ramuri să distrugă ramura principală și permite dezvoltarea simultană în diferite părți ale bazei de cod.

RELATE Cum să alegi fluxul de lucru Git și modelul de ramificare potrivit pentru echipa ta

Pe măsură ce dezvoltările din ramurile laterale sunt finalizate, modificările sunt transferate în ramura principală prin fuzionarea ramurului de dezvoltare în ramura principală. În alte versiuni, sistemele de control care lucrau cu ramuri era dificilă și costisitoare din punct de vedere computațional. Lucrul cu ramuri în Git este foarte rapid și foarte ușor. Ceea ce a fost cândva un exercițiu obositor și adesea evitat în alte sisteme, a devenit banal în Git.

Comanda Git rebase este o altă modalitate de a transfera modificările de la o ramură în alta. Comenzile merge și rebase au obiective similare, dar își ating scopurile în moduri diferite și dau rezultate ușor diferite.

Ce este fuziunea Git?

Deci, pentru ce este comanda Git merge ? Să presupunem că ați creat o ramură numită dev-branch pentru a lucra la o nouă caracteristică.

Faceți câteva comenzi și testați noua funcție. Totul funcționează bine. Acum doriți să trimiteți noua dvs. caracteristică la ramura master . Trebuie să fii în ramura master pentru a îmbina o alta cu ea.

Ne putem asigura că suntem în ramura master verificând-o în mod explicit înainte de a fuziona.

 git checkout master

Acum îi putem spune lui Git să îmbine dev-branch dezvoltare în ramura curentă, care este ramura master .

 git merge dev-branch 

merge noastră este finalizată pentru noi. Dacă verificați ramura master și o compilați, aceasta va avea caracteristica nou dezvoltată în ea. Ceea ce Git a realizat de fapt este o îmbinare în trei căi. compară cele mai recente comite din ramurile master și dev-branch și commit-ul din ramura master imediat înainte de crearea dev-branch . Apoi efectuează un commit pe ramura master .

Îmbinările sunt considerate nedistructive deoarece nu șterg nimic și nu schimbă nimic din istoricul Git. dev-branch încă există și niciunul dintre comiterile anterioare nu este modificat. Este creat un nou commit care surprinde rezultatele îmbinării în trei căi.

După îmbinare, depozitul nostru Git arată ca o cronologie cu o linie alternativă care se ramifică și apoi se întoarce la cronologia principală.

dev-branch a fost încorporată în ramura master .

Dacă aveți o mulțime de ramuri într-un singur proiect, istoria proiectului poate deveni confuză. Acesta este adesea cazul în cazul în care un proiect are mulți colaboratori. Deoarece efortul de dezvoltare se împarte în multe căi diferite, istoria dezvoltării este neliniară. Descurcarea istoricului de comitere devine și mai dificilă dacă ramurile au propriile ramuri.

LEGATE Cum funcționează ramurile Git?

Rețineți că, dacă aveți modificări necommitate în ramura master , va trebui să faceți ceva cu aceste modificări înainte de a putea îmbina ceva cu ea. Puteți crea o nouă ramură și puteți efectua modificările acolo, apoi faceți fuzionarea. Apoi, va trebui să îmbinați ramura temporară înapoi în ramura principală.

Asta funcționează, dar Git are o comandă care realizează același lucru, fără a fi nevoie să creeze noi ramuri. Comanda stash stochează modificările necommitate pentru dvs. și vă permite să le apelați înapoi cu stash pop .

Le-ai folosi astfel:

 ascunde

git merge dev-branch

stash pop

Rezultatul final este o ramură îmbinată, cu modificările nesalvate restaurate.

Ce este Git rebase?

Comanda Git rebase își atinge obiectivele într-un mod complet diferit. Ia toate commit-urile de la ramura pe care urmează să o rebazezi și le redă la capătul ramurii pe care te rebazezi.

Luând exemplul nostru anterior, înainte de a efectua orice acțiune, depozitul nostru Git arată astfel. Avem o ramură numită dev-branch și vrem să mutăm acele modificări în ramura master .

După rebase , arată ca o singură cronologie complet liniară a modificărilor.

dev-branch a fost eliminată, iar commit-urile din dev-branch au fost adăugate la ramura principală. Rezultatul final este același ca și cum commit dev-branch ar fi fost de fapt comise direct în ramura master . Comiterile nu sunt doar fixate pe ramura master , ci sunt „reluate” și adăugate proaspete.

Acesta este motivul pentru care comanda rebase este considerată distructivă. Ramura rebazată nu mai există ca o ramură separată, iar istoricul Git al proiectului dvs. a fost rescris. Nu puteți determina la un moment dat care comite au fost făcute inițial în dev-branch .

Cu toate acestea, vă lasă cu o istorie simplificată, liniară. În comparație cu un depozit cu zeci sau chiar sute de ramuri și îmbinări, citirea jurnalului Git sau utilizarea unei interfețe grafice git pentru a vedea un grafic al depozitului, un depozit rebazat este ușor de înțeles.

Cum să te bazezi pe o altă ramură

Să încercăm un exemplu git rebase . Avem un proiect cu o ramură numită new-feature . Am rebase acea ramură pe ramura master așa.

În primul rând, verificăm dacă ramura master nu are modificări restante.

 starea git

Verificăm new-feature filială.

 git checkout nou-funcție

Îi spunem lui Git să rebase ramura curentă pe ramura principală.

 git rebase master

Putem vedea că mai avem două ramuri.

 ramură git

Trecem înapoi la ramura master

 git checkout master

Îmbinăm ramura nou-funcție în ramura actuală, care în cazul nostru este ramura master .

 git merge new-feature 

Interesant este că mai avem două filiale după fuziunea finală.

Diferența este că acum șeful ramurului new-feature și șeful ramurii master sunt setate să indice aceeași comitere, iar istoricul Git nu arată că era o ramură new-feature separată, în afară de eticheta sucursalei.

Git Rebase vs Merge: pe care ar trebui să-l folosiți?

Nu este un caz de rebase vs merge . Ambele sunt comenzi puternice și probabil le vei folosi pe amândouă. Acestea fiind spuse, există cazuri de utilizare în care rebase nu funcționează chiar atât de bine. Anularea greșelilor cauzate de greșelile folosind merge este neplăcută, dar anularea erorilor cauzate de rebase este infernală.

Dacă sunteți singurul dezvoltator care folosește un depozit, sunt mai puține șanse să faceți ceva cu rebase care este dezastruos. De exemplu, ați putea să vă rebase în direcția greșită și să vă rebase ramura principală pe ramura cu new-feature . Pentru a vă recupera ramura master , va trebui să vă rebase din nou, de data aceasta de la new-feature la ramura master . Asta ți-ar restabili ramura master , deși cu o istorie ciudată.

Nu utilizați rebase pe ramuri partajate în care este posibil să lucreze alții. Modificările dvs. aduse depozitului dvs. vor cauza probleme multor oameni atunci când trimiteți codul rebazat în depozitul dvs. de la distanță.

Dacă proiectul tău are mai mulți contribuitori, lucrul sigur de făcut este să folosești rebase doar în depozitul tău local și nu în ramurile publice. De asemenea, dacă solicitările de extragere fac parte din recenziile dvs. de cod, nu utilizați rebase . Sau cel puțin, nu utilizați rebase după ce ați creat cererea de extragere. Este posibil ca alți dezvoltatori să se uite la comitările dvs., ceea ce înseamnă că acele modificări sunt pe o ramură publică, chiar dacă nu sunt pe ramura master .

Pericolul este că veți rebase care au fost deja trimise într-un depozit de la distanță, iar alți dezvoltatori s-ar putea să-și fi bazat deja munca pe acele comiteri. rebase dvs. locală va face să dispară acele comite existente. Dacă împingeți acele modificări în depozit, nu veți fi popular.

LEGATE Cum să remediați, să editați sau să anulați comiterile Git (modificarea istoricului Git)

Alți contribuitori vor trebui să treacă printr-o merge dezordonată pentru a-și trimite munca înapoi în depozit. Dacă apoi trageți modificările înapoi în depozitul dvs. local, vă confruntați cu dezlegarea unei mizerie de modificări duplicate.

A rebaza sau a nu rebaza?

Rebase ar putea fi scos în afara legii în proiectul dvs. Pot exista obiecții locale, culturale. Unele proiecte sau organizații consideră rebase ca o formă de erezie și un act de profanare. Unii oameni cred că istoria Git ar trebui să fie o înregistrare inviolabilă și permanentă a ceea ce s-a întâmplat. Deci, rebase ar putea fi în afara mesei.

Dar, folosit local, pe sucursale private, rebase este un instrument util.

Apăsați după ce ați rebazat și restricționați-l la ramurile în care sunteți singurul dezvoltator. Sau cel puțin, acolo unde toată dezvoltarea s-a oprit și nimeni altcineva nu a bazat nicio altă lucrare din angajamentele sucursalei tale.

Fă asta și vei evita orice problemă.

RELATE: Cum să verificați și să vă actualizați versiunea Git