de Vali Shah

Introducere în Git Merge și Git Rebase: ce fac și când să le folosească

În calitate de dezvoltator, mulți dintre noi trebuie să aleagă între Merge și Rebase. Cu toate referințele pe care le primim de pe internet, toată lumea crede că „Nu utilizați Rebase, ar putea provoca probleme serioase”. Aici voi explica ce sunt îmbinarea și rebase-ul, de ce ar trebui (și nu ar trebui) să le utilizați și cum să faceți acest lucru.

Git Merge și Git Rebase au același scop. Acestea sunt concepute pentru a integra modificările din mai multe ramuri într-una singură. Deși scopul final este același, aceste două metode îl ating în moduri diferite și este util să cunoașteți diferența pe măsură ce deveniți dezvoltator de software mai bun.

Această întrebare a împărțit comunitatea Git. Unii cred că ar trebui să refaceți întotdeauna și alții că ar trebui să fuzionați întotdeauna. Fiecare parte are unele beneficii convingătoare.

Git Merge

Fuziunea este o practică obișnuită pentru dezvoltatorii care utilizează sisteme de control al versiunilor. Indiferent dacă sunt create sucursale pentru testare, remedierea erorilor sau alte motive, fuziunea face modificări în 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, se modifică doar ramura țintă. Istoria ramurii sursă rămâne aceeași.

Pro

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

Contra

• Istoricul comitetelor poate fi poluat de o mulțime de comitere de îmbinare
• Depanare folosind git bisect poate deveni mai greu

Cum să o facă

Îmbinați ramura principală în ramura caracteristică folosind checkout și merge comenzi.

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

Aceasta va crea un nou „Fuzionează comiterea”În ramura de caracteristici 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 fuzionare, rebasarea aplatizează istoricul, deoarece transferă lucrările finalizate de la o ramură la alta. În acest proces, istoria nedorită este eliminată.

Rebases sunt modul în care schimbările ar trebui să treacă din partea de sus a ierarhiei în jos, iar fuziunile sunt modul în care acestea revin în sus

Pro

• Simplifică o istorie potențial complexă
• Manipularea unei singure comiteri este ușoară (de exemplu, revocarea acestora)
• Evită îmbinarea „zgomotului” de comitere în repo-uri ocupate cu ramuri ocupate
• Curăță confirmările intermediare făcându-le o singură confirmare, ceea ce poate fi util pentru echipele DevOps

Contra

• Reducerea caracteristicii la o mână de confirmări poate ascunde contextul
• Refacerea depozitelor publice poate fi periculoasă atunci când lucrați în echipă
• Este mai mult de lucru: utilizarea rebase-ului pentru a vă menține întotdeauna actualizată ramura de caracteristici
• Refacerea cu ramuri îndepărtate necesită acest lucru forța împinge. Cea mai mare problemă cu care se confruntă oamenii este că forțează push, dar nu au setat implicit git push. Acest lucru are ca rezultat actualizări la toate sucursalele cu același nume, atât local, cât și de la distanță, și asta este îngrozitor a face față.

Dacă refaceți incorect și rescrieți neintenționat istoria, aceasta poate duce la probleme grave, așa că asigurați-vă că știți ce faceți!

Cum să o facă

Reinstalați ramura caracteristică pe ramura principală utilizând următoarele comenzi.

$ git checkout feature
$ git rebase master

Aceasta mută întreaga ramură de caracteristici deasupra ramurii principale. Face acest lucru rescriind istoricul proiectului prin crearea de noi confirmări pentru fiecare confirmare în ramura originală (caracteristică).

Rebasing interactiv

Acest lucru permite modificarea confirmărilor pe măsură ce sunt mutate în noua filială. Aceasta este mai puternică decât rebase-ul automatizat, deoarece oferă control complet asupra istoricului de comitere al sucursalei. De obicei, aceasta este utilizată pentru a curăța un istoric dezordonat înainte de a îmbina o ramură de caracteristici în master.

$ git checkout feature
$ git rebase -i master

Aceasta va deschide editorul listând toate comitetele care urmează să fie mutate.

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

Aceasta definește exact cum va arăta ramura după efectuarea rebasei. Reordonând entitățile, puteți face ca istoria să arate ca orice doriți. De exemplu, puteți utiliza comenzi precum fixup, squash, edit etc, în locul lui pick.

Pe care să îl folosești

Deci, ce e mai bun? 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. 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 reexaminarea 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 dificil să gestionezi sau să urmărești modificările de dezvoltare cu un fuzionează întotdeauna politica. Pentru a avea un istoric de comitere curat și de înțeles, folosind Rebase este rezonabil și eficient.

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

• Vă dezvoltați local: Dacă nu v-ați împărtășit munca cu nimeni altcineva. În acest moment, ar trebui să preferați rebasarea în locul fuzionării pentru a vă menține istoricul ordonat. Dacă aveți furca personală a depozitului și care nu este partajată cu alți dezvoltatori, puteți încerca să refaceți în siguranță chiar și după ce ați trecut la sucursală.
• Codul dvs. este gata pentru examinare: Ați creat o cerere de extragere. Alții îți examinează munca și pot să o aducă în furculița lor pentru examinare locală. În acest moment, nu ar trebui să vă refaceți munca. Ar trebui să creați comitetele „rework” și să vă actualizați ramura de caracteristici. Acest lucru ajută la trasabilitatea cererii de tragere și previne ruperea accidentală a istoricului.
• Revizuirea este terminată ș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 prelua aceste modificări începând cu acest moment, aceasta este șansa ta de a-ți purifica istoricul. În acest moment, puteți rescrie istoricul și plia comitetele originale, iar acele comitente „reprelucrare” și „fuzionare” greoaie într-un set mic de comitere focalizate. Crearea unei îmbinări explicite pentru aceste confirmări este opțională, dar are valoare. Înregistrează când funcția a absolvit funcția de master.

Concluzie

Sper că această explicație a dat câteva informații Git merge și Git rebase. Strategia Merge vs 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.

Aștept cu nerăbdare să scriu mai departe Fluxuri de lucru Git și concepte de Git. Comentează subiectele despre care vrei să scriu în continuare. Noroc!

code = coffee + developer

școală de codare pentru dezvoltatorii de software