O introducere în Git Merge și Git Rebase: Ce fac și când să le folosească

Ca dezvoltator, mulți dintre noi trebuie să alegem între Merge și Rebase. Cu toate referințele pe care le obținem de pe internet, toată lumea crede că „Nu folosiți Rebase, ar putea cauza probleme grave.” Aici voi explica ce sunt combinarea și refacerea, de ce ar trebui (și nu ar trebui) să le folosiți și cum să facă acest lucru.

Git Merge și Git Rebase servesc același scop. Sunt concepute pentru a integra modificările de la mai multe ramuri într-una. Deși obiectivul final este același, aceste două metode îl realizează în moduri diferite și este util să știi diferența pe măsură ce devii un dezvoltator de software mai bun.

Această întrebare a împărțit comunitatea Git. Unii cred că ar trebui să vă întoarceți mereu, iar alții că ar trebui să fuzionați întotdeauna. Fiecare parte are câteva avantaje convingătoare.

Git Merge

Fuziunea este o practică comună pentru dezvoltatori care folosesc sisteme de control al versiunilor. Indiferent dacă ramurile sunt create pentru testare, remedieri de erori sau alte motive, comasarea modificărilor comite în altă locație. Pentru a fi mai specifici, fuziunea preia conținutul unei ramuri sursă și le integrează cu o ramură țintă. În acest proces, doar ramura țintă este modificată. Istoricul ramurii sursă rămâne același.

Merge Master -> Filiala

Pro-uri

  • Simplu și familiar
  • Păstrează istoria completă și ordinea cronologică
  • Menține contextul sucursalei

Contra

  • Istoricul angajamentelor poate deveni poluat de o mulțime de comisioane de fuziune
  • Debugarea folosind git bisect poate deveni mai grea

Cum să o facă

Fuzionează filiera principală în ramura de funcții folosind comenzile de checkout și unire.

Funcție de verificare $ git
$ git master fusion
(sau)
$ git funțiune principală fuziune

Aceasta va crea un nou „Merge angajare” în ramura de funcții care conține istoricul ambelor sucursale.

Git Rebase

Rambursarea este un alt mod de a integra schimbările de la o ramură la alta. Rebase comprimă toate modificările într-un singur „patch”. Apoi integrează patch-ul în ramura țintă.

Spre deosebire de contopire, redresarea aplatizează istoria, deoarece transferă lucrarea finalizată de la o ramură la alta. În acest proces, istoricul nedorit este eliminat.

Reducerile sunt modul în care schimbările ar trebui să treacă de la vârful ierarhiei în jos, iar fuziunile sunt modul în care acestea revin în sus
Reconstruiți ramura caracteristică în master

Pro-uri

  • Simplifică o istorie potențial complexă
  • Manipularea unei singure angajări este ușoară (de exemplu, readucerea acestora)
  • Evită comasarea „zgomotului” în depozite ocupate cu filiale ocupate
  • Curăță angajamentele intermediare făcându-le un singur angajament, care poate fi util pentru echipele DevOps

Contra

  • Reducerea funcției la un pumn de comitete poate ascunde contextul
  • Răsplătirea depozitelor publice poate fi periculoasă atunci când lucrați în echipă
  • Lucrează mai mult: folosind rambursare pentru a vă actualiza întotdeauna filiala de funcții
  • Recoltarea cu ramuri la distanță necesită să forțați apăsarea. Cea mai mare problemă cu care se confruntă oamenii este aceea că forțează apăsarea, dar nu au setat implicit git push. Aceasta duce la actualizări la toate sucursalele cu același nume, atât la nivel local, cât și de la distanță, iar acest lucru este îngrozitor de abordat.
Dacă rescrieți în mod incorect și rescrieți involuntar istoricul, acesta poate duce la probleme serioase, deci asigurați-vă că știți ce faceți!

Cum să o facă

Reconstruiți ramura caracteristică pe ramura principală folosind următoarele comenzi.

Funcție de verificare $ git
$ git stăpânire

Aceasta deplasează întreaga ramură de funcții în partea de sus a ramurii principale. Face acest lucru prin rescrierea istoricului proiectului prin crearea de noi angajamente pentru fiecare angajare din ramura originală (caracteristică).

Revenimentare interactivă

Aceasta permite modificarea comiterilor pe măsură ce sunt mutate în noua sucursală. Acest lucru este mai puternic decât rambursarea automată, deoarece oferă un control complet asupra istoriei angajamentelor sucursalei. În mod obișnuit, acest lucru este utilizat pentru a curăța un istoric dezordonat înainte de contopirea unei ramuri de funcții cu master.

Funcție de verificare $ git
$ git rebase -i stăpân

Aceasta va deschide editorul prin listarea tuturor angajamentelor care urmează să fie mutate.

alegeți 22d6d7c Mesajul de angajare # 1
alege 44e8a9b Mesajul de angajare # 2
alege 79f1d2h Mesajul de angajare # 3

Aceasta definește exact cum va arăta ramura după efectuarea rambursării. Recomandând entitățile, puteți face ca istoricul să arate ca orice doriți. De exemplu, puteți utiliza comenzi precum fixup, squash, edit etc., în loc de pick.

Care să folosească

Deci, ce e mai bine? Ce recomandă experții?

Este greu să generalizezi și să decizi unul sau altul, deoarece fiecare echipă este diferită. Dar trebuie să pornim undeva.

Echipele trebuie să ia în considerare mai multe întrebări atunci când își stabilesc rambursarea Git vs. politicile de fuziune. Deoarece, după cum se dovedește, o strategie a fluxului de lucru nu este mai bună decât cealaltă. Depinde de echipa ta.

Luați în considerare nivelul de reînnoire și competența Git în întreaga organizație. Determinați gradul în care apreciați simplitatea revanzării în comparație cu trasabilitatea și istoricul contopirii.

În cele din urmă, deciziile privind comasarea și reîncadrarea ar trebui luate în considerare în contextul unei strategii clare de ramificare (Consultați acest articol pentru a înțelege mai multe despre strategia de ramificare). O strategie de succes de ramificare este concepută în jurul organizării echipelor tale.

Ce recomand?

Pe măsură ce echipa crește, va deveni greu de gestionat sau de urmărit modificările de dezvoltare cu o politică de fuziune întotdeauna. Pentru a avea un istoric de angajament curat și inteligibil, utilizarea Rebase este rezonabilă și eficientă.

Luând în considerare următoarele circumstanțe și orientări, puteți obține cel mai bine din Rebase:

  • Te dezvolți local: dacă nu ai împărtășit munca cu nimeni altcineva. În acest moment, ar trebui să preferați să reveniți decât să fuzionați pentru a vă păstra istoria ordonată. Dacă aveți forfața personală a depozitului și aceasta nu este împărtășită cu alți dezvoltatori, sunteți în siguranță să vă retrageți chiar și după ce ați fost împins către sucursală.
  • Codul dvs. este gata de revizuire: ați creat o solicitare de tragere. Alții îți examinează munca și pot intra în furculița lor pentru a le examina local. În acest moment, nu ar trebui să-ți retrasezi munca. Ar trebui să creați comisioane „reelaborate” și să actualizați ramura de caracteristici. Acest lucru ajută la trasabilitate în cererea de tragere și previne ruperea accidentală a istoricului.
  • Revizuirea este făcută și gata de a fi integrată în sucursala țintă. Felicitări! Ești pe cale să ștergi sucursala funcțională. Având în vedere că alți dezvoltatori nu se vor contopi în aceste modificări de la acest moment, aceasta este șansa dvs. de a vă igieniza istoricul. În acest moment, puteți rescrie istoricul și pliați comitele originale și acele angajamente neplăcute „re-rework” și „merge” într-un set mic de comitete focalizate. Crearea unei fuziuni explicite pentru aceste angajamente este opțională, dar are valoare. Se înregistrează când funcția a absolvit masterul.

Concluzie

Sper că această explicație a oferit câteva informații despre fuziunea Git și reîncadrarea Git. Strategia de combinare vs rambursare este întotdeauna discutabilă. Dar, probabil, acest articol vă va ajuta să risipiți îndoielile dvs. și vă va permite să adoptați o abordare care funcționează pentru echipa dvs.

Aștept cu nerăbdare să scriu pe fluxuri de lucru Git și concepte despre Git. Comentați subiectele pe care doriți să le scriu. Noroc!

cod = cafea + dezvoltator

Iată o altă referință utilă

  • Cum să adopți o strategie de ramificare Git

școală de codificare pentru dezvoltatorii de software