După utilizarea Git de mai mulți ani, m-am trezit, treptat, folosind mai multe și mai avansate Git comenzi de lucru zilnic. La scurt timp după ce am descoperit git rebase, l-am încorporat rapid în fluxul meu de lucru zilnic. Cei care sunt familiarizați cu rebasing știu cât de puternic este un instrument și cât de tentant este să-l folosești tot timpul. Cu toate acestea, am descoperit curând că rebasing prezintă unele provocări care nu sunt evidente atunci când începeți să o faceți pentru prima dată. Înainte de a le prezenta, voi recapitula rapid diferențele dintre fuzionare și rebasing.,

să luăm în considerare mai întâi exemplul de bază în care doriți să integrați o ramură de caracteristici cu master. Prin fuziune, creăm un nou commit g care reprezintă îmbinarea dintre cele două ramuri. Graficul de comitere arată clar ce s-a întâmplat și putem vedea contururile graficului „tren” familiar din git-repo-urile mai mari.,

Alternatively, we could rebase before merging. The commits are removed and the feature branch is reset to master, after which the commits are re-applied on top of feature., Diff – urile acestor comiteri reaplicate sunt de obicei identice cu omologii lor originali, dar au comiteri părinte diferite și, prin urmare, chei SHA-1 diferite.

Ne-am schimbat acum baza comite de feature de la b și c, literalmente re-bazându-se., Merging feature to masteris now a fast-forward merge, because all commits on feature are direct descendants of master.

Compared to the merge approach, the resulting history is linear with no divergent branches., Lizibilitatea îmbunătățită a fost motivul pentru care preferam să rebasez ramurile înainte de a fuziona și mă aștept ca acest lucru să fie cazul și pentru alți dezvoltatori.cu toate acestea, această abordare are unele provocări care nu pot fi evidente.

luați în Considerare cazul în care o dependență care este încă în uz pe feature a fost eliminat de pe master. Când featureeste indexat pe master, prima re-aplicat comite va rupe construi, dar atâta timp cât nu există fuziona conflicte, rebazare procesul va continua neîntrerupt., Eroarea de la prima comitere va rămâne prezentă în toate comiterile ulterioare, rezultând într-un lanț de comiteri rupte.

Această eroare este descoperită doar după rebazare procesul este terminat, și este, de obicei, stabilită prin aplicarea unui nou bugfix comite g pe partea de sus.,

Dacă ai conflicte în timpul rebasing cu toate acestea, Git, se va întrerupe pe contradictorii comis-o, permițându-vă pentru a rezolva conflictul înainte de a continua. Rezolvarea conflictelor în mijlocul rebasing un lanț lung de comite este adesea confuz, greu pentru a obține dreptul, și o altă sursă de erori potențiale.

introducerea erorilor este foarte problematică atunci când se întâmplă în timpul rebasing., În acest fel, noi erori sunt introduse atunci când rescrieți istoria și pot ascunde bug-uri autentice care au fost introduse atunci când istoria a fost scrisă pentru prima dată. În special, acest lucru va face mai dificilă utilizarea Git bisect, probabil cel mai puternic instrument de depanare din git toolbox. De exemplu, luați în considerare următoarea ramură de caracteristici. Să presupunem că am introdus un bug spre sfârșitul ramurii.,

se poate sa nu descoperi acest bug, până la săptămâni după ramura a fuzionat cu master. Pentru a găsi comiterea care a introdus eroarea, este posibil să trebuiască să căutați prin zeci sau sute de comiteri., Acest proces poate fi automatizat scriind un script care testează prezența bug-ului și rulându-l automat prin GIT bisect, folosind comanda git bisect run <yourtest.sh>.Bisect va efectua o căutare de bisecție prin istoric, identificând comiterea care a introdus eroarea. În exemplul de mai jos, reușește să găsească prima comitere defectuoasă, deoarece toate comiterile rupte conțin eroarea reală pe care o căutăm.,

On the other hand, if we’ve introduced additional broken commits during rebasing (here, d and e), bisect will run into trouble., În acest caz, sperăm că Git identifică comite f ca fiind cea rea, dar se identifică în mod eronat dîn loc, deoarece conține alte erori care rupe test.

Această problemă este mai mare decât ar putea părea la prima vedere.

de ce folosim Git deloc?, Pentru că este instrumentul nostru cel mai important pentru urmărirea sursei de bug-uri din Codul nostru. Git este Plasa noastră de siguranță. Prin rebasing, acordăm acestei priorități mai puțin, în favoarea dorinței de a realiza o istorie liniară.cu ceva timp în urmă, a trebuit să trec prin câteva sute de angajamente pentru a urmări o eroare în sistemul nostru. Comiterea defectuoasă a fost localizată în mijlocul unui lanț lung de comiteri care nu au fost compilate, din cauza unei rebase defectuoase pe care un coleg a efectuat-o. Această eroare inutilă și total evitabilă a dus la faptul că am petrecut aproape o zi în plus în urmărirea comiterii.,deci, cum putem evita aceste lanțuri de comiteri rupte în timpul rebasing? O abordare ar putea fi de a lăsa procesul de rebase termina, testa codul pentru a identifica orice bug-uri, și du-te înapoi în istorie pentru a repara bug-uri în cazul în care au fost introduse. În acest scop, am putea folosi rebasing interactiv.o altă abordare ar fi de a avea pauză Git în timpul fiecărui pas al procesului de rebase, testa pentru orice bug-uri și să le stabilească imediat înainte de a continua.acesta este un proces greoi și predispus la erori, iar singurul motiv pentru a face acest lucru ar fi realizarea unei istorii liniare. Există o cale mai simplă și mai bună?,

există; Git merge. Este un proces simplu, într-un singur pas, în care toate conflictele sunt rezolvate într-o singură comitere. Îmbinarea rezultată marchează clar punctul de integrare dintre ramurile noastre, iar istoria noastră descrie ce s-a întâmplat de fapt și când s-a întâmplat.importanța păstrării istoriei adevărate nu trebuie subestimată. Prin rebasing, te minți pe tine și pe echipa ta. Pretinzi că comiterile au fost scrise astăzi, când au fost de fapt scrise ieri, pe baza unei alte comiteri., Ai scos comiterile din contextul lor original, deghizând ceea ce s-a întâmplat de fapt. Poți fi sigur că codul construiește? Puteți fi sigur că mesajele de comitere au încă sens? S-ar putea să credeți că vă curățați și clarificați istoria, dar rezultatul poate fi foarte bine invers.

este imposibil să spui ce erori și provocări aduce viitorul pentru baza de cod. Cu toate acestea, puteți fi sigur că o istorie adevărată va fi mai utilă decât una rescrisă (sau falsă).