Diferența dintre Git ReBase și Merge
În acest articol, vom discuta despre două astfel de instrumente Rebase și Merge și diferența lor. GIT este unul dintre cele mai frecvent utilizate controlere de versiune distribuite DVCS în rândul programatorilor, datorită naturii sale dinamice și a disponibilității vaste a instrumentelor pentru a gestiona versiunile. Există două modalități prin care ne putem trimite modificările de la o ramură la alta. Unul este folosind Rebase, iar celălalt este Merge, care este destul de popular. Mai jos aflăm cea mai bună comparație între Git ReBase și Merge.
Comparație față în față între Git ReBase și Merge (Infografie)
Mai jos se află primele 5 comparații între Git ReBase și Merge:
Diferențe cheie între Git ReBase și Merge
Să discutăm diferența cheie dintre Git ReBase și Merge:
1. Git Rebase
Git Rebase își începe activitatea dintr-un angajament comun între cele două ramuri. Maestru și caracteristică, de aici le compară pe ambele și surprinde imaginea diferenței care se face într-una dintre ramuri și apoi o adaugă la altele. Să ne uităm la acest lucru cu capturile de ecran de mai jos.
Să ne imaginăm că avem o filială principală și cel mai recent angajăm să-l m2 așa cum se arată în imaginea de mai sus. Din acest commit, am creat o ramură de funcții și am făcut unele modificări și angajăm cu mesajul f1. Acum să luăm în considerare că cineva și-a contopit munca cu stăpânul și acum cea mai recentă angajare a maestrului este m3, nu m2 așa cum se arată mai jos.
De asemenea, continuăm să lucrăm la ramura de funcții pentru a adăuga cele mai recente angajamente ale sale de a fi f2, așa cum se arată mai jos.
Așa cum se vede deasupra screengrab-ului, am stăpânit cel mai recent commit m3 și avem o caracteristică care nu este actualizată cu masterul, deoarece a fost creată de la m2 commit snapshot, care are cea mai recentă comutare ca f3. Acum, pentru a combina aceste eforturi cu maestrul de a genera este prezentat mai jos.
Acum trebuie să integrăm modificările de mai sus, care pot fi făcute în două moduri, unul cu fuziune, iar altul cu revanșare. Aici vom analiza cum să ne integrăm cu rambursarea.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Din comanda de rambursare de mai sus, vom încerca să căutăm un angajament comun atât din partea principalului, cât și din funcție, iar în acest caz, este m2. Și atunci din moment ce trebuie să rebasăm masterul, acesta va căuta adăugări care au fost făcute cu master și să ia snapshot m3 și caracteristica rebase de la m2 la m3. Acum avem o caracteristică cu m3 (în loc de m2), f1, f2. Acum pot aplica pentru a reîncasa funcția pentru a face actualizarea filialei master cu modificările funcției. Un lucru de reținut este orice modificare a masterului trebuie să fie auditată. Aici arată doar un exemplu.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
În acest caz, vom aplica cea mai recentă ramură de caracteristică de comitere care este f2 la master și ultima instantanee de comitere a masterului va fi f2. Puteți enumera angajamentele folosind comanda git log, dar trebuie să verificăm mai întâi în ce ramură trebuie să vedem jurnalul ca mai jos.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Acum, cu rambursare, am integrat actualizările unei funcții pe care să le stăpânim. Să încercăm să realizăm acest lucru prin fuziune.
2. Git Merge
Vom folosi și ecranul de mai sus pentru referință aici și putem realiza același lucru pe care l-am obținut cu rebase și, de asemenea, să fuzionăm.
Git merge comite ultimul angajament pe care l-am avut în ramura funcțională și aici este cazul cu f2 commit, care adună toate modificările și îl contopește cu cea mai recentă angajare pe care o avem în ramura principală, m3 aici. Acest lucru pare complicat, dar poate fi executat cu ușurință prin comanda de îmbinare. Putem face fie o contopire directă, fie combinarea cu squash și diferența în ambele.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Comanda de mai sus va lua toate comiterile de caracteristică și va adăuga și în jurnalul de master. Pentru a evita că putem folosi squash, astfel încât în jurnalul maestrului, după m3, o singură angajare să fie actualizată
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
trebuie să aveți grijă în timp ce utilizați git rebase și să încercați să îl evitați. Regula de aur este să o evitați folosind filiale publice.
Uită-te la scenariul de mai sus. Acest lucru se poate întâmpla atunci când încercați să retrăiți masterul deasupra filialei dvs. funcționale și sucursala noastră principală este publică, acum sucursala principală este actualizată, dar toți ceilalți lucrează la o versiune mai veche de master. Având în vedere că rambursarea va avea ca rezultat angajamente noi, git poate crede că istoria filialei principale a divergent de la toți ceilalți. Singura modalitate de a rezolva acest lucru va fi sincronizarea atât a maestrului, prin îmbinarea lor împreună, cât și un set de angajamente rezultate care va fi confuz.
Tabelul de comparație al Git ReBase vs Merge
Tabelul de mai jos rezumă comparațiile dintre Git ReBase și Merge:
| Baza de comparație între Rebase și Merge | rebase | Combina |
| încredințarile | Modifică și rescrie istoricul prin crearea unui nou angajament pentru fiecare angajare din sucursala sursa. | Incorporează toate modificările la sursă, dar menține antecedențele fiecărui istoric de angajare încorporează toate modificările sursei, dar menține antecedențele fiecărui istoric de comitere. |
| Selecţie | Aici vom verifica mai întâi sucursala care trebuie refasată, apoi selectăm comanda de rambursare pentru a-l adăuga actualizări altora. | Aici verificați mai întâi sucursala care trebuie fuzionată mai întâi. Apoi, efectuați operațiunea de îmbinare și cea mai recentă angajare a sursei va fi contopit cu cel mai recent angajament al stăpânului. |
| Tratarea conflictelor | Deoarece istoricul angajamentelor va fi rescris pentru a înțelege conflictul va fi dificil unele cazuri. | Conflictul de îmbinare poate fi ușor gestionat înțelegând greșeala care a fost efectuată în timpul fuziunii. |
| regula de aur | Ar trebui să fie utilizat pe sucursalele publice, deoarece istoricul de comitere poate provoca confuzie. | Niciun rău în timpul executării filialelor publice. |
| accesibilitate | Angajamentele care au fost odată accesibile nu vor mai fi accesibile după rambursare, deoarece istoria comisiei este modificată. | Angajamentele vor rămâne accesibile din ramurile sursă. |
Concluzie
Merge și Rebase sunt câteva două instrumente puternice ale Git și ambele sunt folosite pentru a încorpora modificările la sucursale, dar trebuie să fim un pic atenți cu rambursarea, deoarece va rescrie istoricul angajamentelor și utilizarea lor pe sucursalele publice poate împiedica munca a altora provocându-le confuzie. Întrucât puteți utiliza opțiunea de îmbinare, deoarece angajamentele sale pot fi accesate de la sucursala sursă și puteți rezolva cu ușurință conflictele de îmbinare dacă avem o înțelegere corectă.
Articole recomandate
Acesta este un ghid pentru diferența maximă dintre Git ReBase și Merge. Aici vom discuta, de asemenea, diferențele cheie Git ReBase vs Merge cu infografie și tabelul de comparație. De asemenea, puteți arunca o privire la următoarele articole pentru a afla mai multe -
- Git Fetch vs Git Pull - diferențe de top
- Abstracție vs încapsulare | Top 6 Comparație
- HBase Architecture with Avantages
- Întrebări pentru interviu GIT | Top 11
- Sistem de control al versiunilor GIT
- Git Push
- Încapsulare în JavaScript
- Ghid complet de comandă la distanță Git
- Trei etape ale ciclului de viață al gitului cu fluxul de lucru
- Cum se utilizează GIT Cherry-pick cu Exemplu?