de Vali Shah

Ca un Dezvoltator, mulți dintre noi trebuie să aleagă între a Merge și Rebazare. Cu toate referințele pe care le obținem de pe internet, toată lumea crede că „nu folosiți Rebase, ar putea provoca probleme grave.”Aici voi explica ce sunt merge și rebase, de ce ar trebui (și nu ar trebui) să le folosiți și cum să faceți acest lucru.

Git Merge și git Rebase servesc același scop. Acestea sunt concepute pentru a integra schimbările din mai multe ramuri într-una., Deși scopul final este același, aceste două metode îl realizează în moduri diferite și este util să cunoașteți diferența pe măsură ce deveniți un dezvoltator de software mai bun.această întrebare a împărțit comunitatea Git. Unii cred că ar trebui să rebase întotdeauna și alții că ar trebui să fuzioneze întotdeauna. Fiecare parte are unele beneficii convingătoare.

Git Merge

fuzionarea este o practică obișnuită pentru dezvoltatorii care utilizează sisteme de control al versiunilor. Indiferent dacă sucursalele sunt create pentru testare, remedieri de erori sau din alte motive, fuzionarea comite modificări într-o altă locație., Pentru a fi mai specific, fuzionarea ia conținutul unei ramuri sursă și le integrează cu o ramură țintă. În acest proces, numai ramura țintă este schimbată. Istoria ramurii sursă rămâne aceeași.,da2a4595a”>

Fuziona Master -> caracteristici ramură

Pro

  • Simplu și familiar
  • Păstrează istorie completă și ordinea cronologică
  • Mentine contextul ramură

Dezavantaje

  • Comite istorie poate deveni poluat de o mulțime de îmbinare se angajează
  • Depanare folosind git bisect poate deveni mai greu

Cum să facă asta,

Merge ramura de master în funcție de ramură folosind checkout și merge comenzi.,

$ git checkout feature$ git merge master(or)$ git merge master feature

Acest lucru va crea un nou „Merge commit” în ramura caracteristică care deține istoria ambelor ramuri.

Git Rebase

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

spre deosebire de fuziune, rebasing aplatizează istoria, deoarece transferă lucrarea finalizată de la o ramură la alta. În acest proces, Istoricul nedorit este eliminat.,

Rebases sunt ce schimbări ar trebui să treacă de la partea de sus a ierarhiei în jos, și fuzionează sunt cum le curge înapoi în sus

Rebazare caracteristică ramură în master

Pro

  • Simplifică un potențial complex istorie
  • Manipularea un singur comite este ușor (de ex., revenirea ei)
  • Evită merge comite „zgomot” în ocupat repos ocupat cu ramuri
  • Curăță intermediare se angajează, făcându-le un singur comite, care pot fi utile pentru DevOps echipe

Dezavantaje

  • Strivești caracteristica jos pentru un pumn de comite poate ascunde context
  • Rebasing publice centrale de tranzacții pot fi periculoase atunci când se lucrează în echipă
  • e mai mult de lucru: Folosind rebazare pentru a păstra caracteristica de ramură actualizat întotdeauna
  • Rebasing cu sucursalele izolate necesită forța de împingere., Cea mai mare problemă cu care se confruntă oamenii este că forțează împingerea, dar nu au setat implicit git push. Acest lucru duce la actualizări pentru toate ramurile cu același nume, atât la nivel local, cât și de la distanță, și este îngrozitor de rezolvat.

dacă rebase incorect și neintenționat rescrie istoria, aceasta poate duce la probleme grave, astfel încât asigurați-vă că știți ce faci!

cum se face

Rebase ramura caracteristică pe ramura master folosind următoarele comenzi.,

$ git checkout feature$ git rebase master

aceasta mută întreaga ramură caracteristică deasupra ramurii master. Face acest lucru prin re-scrierea istoricului proiectului prin crearea de noi comiteri pentru fiecare comitere în ramura originală (caracteristică).

Rebasing interactiv

aceasta permite modificarea angajamentelor pe măsură ce acestea sunt mutate în noua ramură. Acest lucru este mai puternic decât rebase automat, deoarece oferă un control complet asupra istoriei comite sucursalei. De obicei, acest lucru este folosit pentru a curăța o istorie dezordonată înainte de a fuziona o ramură de caracteristici în master.,

$ git checkout feature$ git rebase -i master

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

pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

aceasta definește exact cum va arăta ramura după efectuarea rebazării. Prin re-ordonarea entităților, puteți face istoria să arate ca orice doriți. De exemplu, puteți utiliza comenzi ca fixup, squash, edit etc, în loc de pick.

Care o să folosească

Deci, ce e mai bine?, Ce recomandă experții?este greu să generalizezi și să decizi una sau alta, deoarece fiecare echipă este diferită. Dar trebuie să începem de undeva.

Echipele trebuie să ia în considerare mai multe întrebări atunci când își stabilesc politicile git rebase vs.merge. Pentru că, după cum se dovedește, o strategie de flux de lucru nu este mai bună decât cealaltă. Depinde de echipa ta.

luați în considerare nivelul de rebasing și competența Git în întreaga organizație. Determinați gradul în care apreciați simplitatea rebasării în comparație cu trasabilitatea și istoricul fuziunii.,în cele din urmă, deciziile privind fuzionarea și rebasarea 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 ramificare de succes este concepută în jurul organizării echipelor dvs.

ce recomand?

pe măsură ce echipa crește, va deveni greu să gestionați sau să urmăriți schimbările de dezvoltare cu o politică always merge. Pentru a avea un istoric de comitere curat și ușor de înțeles, utilizarea Rebase este rezonabilă și eficientă.,

luând în considerare următoarele circumstanțe și instrucțiuni, puteți obține cele mai bune rezultate din Rebase:

  • pe care îl dezvoltați local: dacă nu ați împărtășit munca dvs. cu nimeni altcineva. În acest moment, ar trebui să preferați rebasing peste fuzionarea pentru a vă menține istoricul ordonat. Dacă aveți furculița personală a depozitului și care nu este partajată cu alți dezvoltatori, sunteți în siguranță să faceți rebase chiar și după ce ați împins la sucursala dvs.
  • codul dvs. este gata pentru examinare: ați creat o solicitare pull. Alții vă revizuiesc munca și o pot aduce în furculița lor pentru revizuire locală., În acest moment, nu ar trebui să vă rebasați munca. Ar trebui să creați „reprelucrare” comite și actualiza sucursala caracteristică. Acest lucru ajută la trasabilitatea cererii de tragere și previne ruperea accidentală a istoricului.
  • revizuirea este făcută și gata să fie integrată în ramura țintă. Felicitări! Ești pe cale să-ți ștergi ramura de funcții. Având în vedere că alți dezvoltatori nu vor fi implicați în aceste schimbări din acest moment, aceasta este șansa dvs. de a vă igieniza Istoricul., În acest moment, puteți rescrie istoricul și plia comiterile originale și acele „reprelucrări pr” și „îmbinare” comiteri într-un set mic de comiteri concentrate. Crearea unei fuziuni explicite pentru aceste comiteri este opțională, dar are valoare. Înregistrează când funcția a absolvit să stăpânească.

concluzie

sper că această explicație a dat câteva informații despre git merge și git rebase. Merge vs strategie rebase este întotdeauna discutabil. Dar poate că acest articol vă va ajuta să vă risipiți îndoielile și vă va permite să adoptați o abordare care să funcționeze pentru echipa dvs.