Rebase interactiv este uneori numit „cuțitul elvețian” al lui Git – deoarece conține atât de multe instrumente diferite, pentru atât de multe cazuri de utilizare diferite! Cu toate acestea, există un caz de utilizare principal, primordial: curățarea istoricului de confirmare local.

Rețineți cuvântul „local”: ar trebui să fie utilizat numai pentru curățarea propriului istoric de confirmare local, de exemplu înainte de a integra una dintre ramurile de caracteristici într-o ramură de echipă. În schimb, NU ar trebui să fie utilizat pe istoricul de confirmare care a fost deja împins și partajat pe un depozit la distanță. Rebase interactiv este unul dintre acele instrumente care „rescriu” istoricul Git – și nu ar trebui să faceți acest lucru pe angajamente care au fost deja partajate cu alții.

După ce acest mic mesaj de avertizare a fost eliminat, să ne uităm la câteva exemple practice!

Nota: pentru o vizualizare mai ușoară a scenariilor și a fluxurilor de lucru din această postare, am folosit GUI-ul desktop Git „Tower” în unele dintre capturile mele de ecran.

Corectarea unui mesaj de confirmare vechi

Cîteodată observați o greșeală de scriere într-un mesaj de confirmare vechi – sau ați uitat să menționați ceva în descriere care este demn de menționat. Dacă ar fi fost vorba despre ultima confirmare, am fi putut folosi pur și simplu opțiunea --amend a comenzii git commit. Dar, pentru confirmările mai vechi, va trebui să folosiți rebase interactiv pentru a le modifica după aceea.

Iată un exemplu de mesaj de confirmare care a mers groaznic de prost și pe care dorim să îl corectăm:

Un mesaj de confirmare prost care trebuie corectat

Primul pas în orice sesiune de rebase interactiv este să determinați ce parte din istoricul confirmărilor doriți să manipulați. Să luăm din nou exemplul de mai sus: pentru a modifica acest commit rău trebuie să începem sesiunea de la commitul său părinte.

Începem sesiunea noastră interactivă de rebase

Acum putem introduce hash-ul acestui commit de pornire în comanda interactivă de rebase:

$ git rebase -i 0023cddd

Se va deschide acum o fereastră a editorului, care va conține o listă a commiturilor pe care tocmai le-ați selectat pentru manipulare. Și nu fiți surprinși pentru că acestea sunt în ordine inversă: într-o sesiune de rebase interactivă, Git va reaplica vechile commits, element după element – ceea ce înseamnă că inversarea ordinii este corectă din perspectiva lui Git.

Fereastra editorului cu commits selectate

Un alt lucru important de reținut în legătură cu această fereastră a editorului: aici nu efectuați manipulările propriu-zise! Sau, în acest exemplu concret, NU treceți la modificarea mesajului de confirmare aici. În schimb, doar marcați confirmarea pe care doriți să o modificați cu un cuvânt cheie de acțiune. În cazul nostru, deoarece dorim să modificăm mesajul unei confirmări, marcăm linia cu „reword”. Dacă apoi salvați și închideți această fereastră a editorului, se va deschide una nouă, care va conține mesajul vechiului commit. Acum este momentul să faceți în sfârșit modificările:

În sfârșit, putem face modificările noastre

După salvarea și închiderea încă o dată, sesiunea de rebase interactiv este completă și mesajul vechiului nostru commit a fost corectat!

Combinarea mai multor commit-uri într-unul singur

Un alt caz de utilizare a rebase-ului interactiv este atunci când doriți să combinați mai multe comentarii vechi într-unul singur. Deși, bineînțeles, se aplică regula de aur a controlului versiunilor: în majoritatea situațiilor, este benefic să creați mai multe și mai mici comenzi în loc de câteva mari. Cu toate acestea, la fel ca în cazul tuturor lucrurilor, s-ar putea să ne dăm seama că am exagerat și că acum dorim să unim două sau mai multe comenzi vechi într-unul singur.

Pentru a da un exemplu concret, să spunem că dorim să combinăm următoarele commits selectate într-unul singur:

Să combinăm mai multe commits într-unul singur

La fel ca în primul nostru caz, începem prin a începe sesiunea interactivă de rebase cel puțin la commit-ul părinte al celui pe care dorim să îl manipulăm.

$ git rebase -i 2b504bee

Din nou, se va deschide o fereastră a editorului, care va enumera acea parte din istoricul nostru de confirmare pe care dorim să o manipulăm:

Marcarea liniilor cu „squash”

Cuvântul cheie de acțiune pe care îl vom folosi aici se numește „squash”. Și există o singură informație importantă pe care trebuie să o cunoașteți despre squash pentru a o folosi: linia pe care o marcăm cu cuvântul cheie „squash” va fi combinată cu linia de deasupra. De aceea, după cum puteți vedea în captura mea de ecran de mai sus, am marcat linia nr. 2 cu „squash” pentru a o combina cu linia nr. 1.

Acum putem să salvăm și să închidem fereastra editorului și din nou să privim și să apară o nouă fereastră: acum ni se cere să furnizăm un mesaj de confirmare pentru noua confirmare care este creată prin combinarea celor două vechi.

Introducerea unui nou mesaj pentru noul comitet strivit

După salvarea și închiderea acestei ferestre de editor, veți vedea că a fost creat un nou comitet care conține seturile de modificări ale ambelor comitete vechi. Voila!

Corectarea unei greșeli

Un alt caz de utilizare a rebase-ului interactiv este atunci când ați găsit o greșeală într-una din confirmările dvs. anterioare. Și nu contează ce anume ați greșit: ați putut uita să adăugați o anumită modificare, ar fi trebuit să ștergeți un fișier, sau pur și simplu ați introdus o greșeală de scriere…

Tendința naturală, într-o astfel de situație, este de a crea pur și simplu un nou commit care să corecteze greșeala. Dar, pe de altă parte, acest lucru va încurca istoricul nostru de confirmări: a face o confirmare originală și apoi a adăuga o confirmare „band-aid” doar pentru a corecta unele greșeli… este un mod dezordonat de lucru. Istoricul de confirmare va deveni în curând greu de înțeles, pentru că este presărat cu toate aceste mici „confirmări de remediere rapidă”!

Acesta este momentul în care „fixup”, unul dintre instrumentele care vin cu rebase interactiv, vine foarte la îndemână. Fixup ia această confirmare „quick fix”, aplică modificările sale la confirmarea originală (corectând-o astfel) și apoi scapă de confirmarea „bandaj”:

Cum funcționează „fixup”

După ce am terminat, arată ca și cum nu ar fi existat niciodată o problemă cu confirmarea noastră originală! Așa că haideți să parcurgem acest lucru folosind un exemplu practic.

Primul pas este să faceți tot ce este necesar pentru a remedia problema: acest lucru poate însemna adăugarea unui nou fișier, efectuarea de modificări la cele existente, ștergerea fișierelor învechite… trebuie „doar” să produceți modificările care corectează greșeala.

Postul următor este să trimitem aceste modificări în depozit – dar cu ceva în plus: atunci când facem confirmarea, vom folosi flag-ul --fixup și îi vom spune lui Git hash-ul de confirmare al confirmării noastre greșite:

$ git add corrections.txt$ git commit --fixup 2b504bee

Când vă uitați acum la istoricul confirmărilor, veți vedea că a fost creată o confirmare cu aspect destul de obișnuit – probabil nu magia și artificiile la care v-ați fi așteptat. Dar dacă vă uitați mai atent, veți vedea că se întâmplă ceva: noul commit a fost automat preapreciat cu „fixup !” și cu subiectul commit-ului nostru greșit.

Commitentul original și commit-ul de corecție

Cel de-al treilea pas acum este de a începe sesiunea interactivă de rebase. Din nou, alegem ca punct de plecare părintele confirmării noastre greșite…

$ git rebase -i 0023cddd --autosquash

… și, ca a doua parte a sosului secret, folosim steagul --autosquash. Această opțiune ne asigură că nu trebuie să facem nimic în fereastra editorului care este acum deschisă. Priviți cu atenție situația:

Compromisiunea noastră de remediere este marcată „fixup” și ordonată în poziția corectă

Veți vedea că Git a făcut automat două lucruri pentru noi:

1. A marcat comisionul nostru de remediere ca fiind „fixup”.”
2. A reordonat liniile astfel încât confirmarea noastră band-aid să apară direct sub confirmarea noastră proastă. Acest lucru se datorează faptului că fixup funcționează exact ca și squash, în sensul că se combină cu linia de mai sus.

Cu alte cuvinte: nu a mai rămas nimic de făcut pentru noi decât să salvăm și să închidem fereastra editorului.

Să aruncăm o altă privire la istoricul confirmărilor:

Un final fericit!

Nu numai că confirmarea noastră inițial proastă conține acum modificările din confirmarea noastră band-aid. Dar, pe deasupra, comiterea urâtă a band-aidului a dispărut din istoricul de comitere! Totul este frumos și curat, ca și cum nu ar fi existat niciodată o problemă!

Descoperiți puterea rebase-ului interactiv

Există o mulțime de cazuri de utilizare pentru rebase-ul interactiv – și cele mai multe dintre ele în departamentul de „reparare a greșelilor”. Pentru o trecere în revistă a altor lucruri utile pe care le puteți face, vă recomand gratuit „First Aid Kit for Git”: este o colecție de videoclipuri scurte (2-3 min pe episod) care vă ajută să învățați să reparați greșeli folosind rebase interactiv și alte instrumente Git.

Nota editorului: A trebuit să folosesc rebase interactiv când am revizuit chiar acest post! Una dintre confirmările mele a inclus o imagine care era mai mare de 1MB, ceea ce este împotriva regulilor pentru proiectul de site GitLab. A trebuit să mă întorc și să corectez acel commit pentru a include în schimb o imagine de dimensiuni corecte. Mulțumesc pentru lecție, universule! 😁

Mai multe sfaturi și trucuri Git

• 15 sfaturi Git pentru a vă îmbunătăți fluxul de lucru
• Cum Git Partial Clone vă permite să preluați doar fișierul mare de care aveți nevoie
• Git se întâmplă! 6 greșeli comune Git și cum să le remediați

Despre autorul invitat

Tobias Günther este CEO al Tower, popularul client desktop Git care ajută peste 100.000 de dezvoltatori din întreaga lume să fie mai productivi cu Git.

Imaginea de copertă de David Taljat pe Pexels