Forskellen mellem Git ReBase vs Merge
I denne artikel diskuterer vi to sådanne værktøjer Rebase and Merge og deres forskel. GIT er en af de mest almindeligt anvendte distribuerede versionskontroller DVCS blandt programmererne på grund af dens dynamiske karakter og enorme værktøjstilgængelighed til at håndtere versionerne. Der er to måder, hvorpå vi kan sende vores ændringer fra en gren til en anden. Den ene er ved at bruge Rebase og den anden er Fletning, som er ret populær. Nedenfor lærer vi den øverste sammenligning mellem Git ReBase vs Merge.
Sammenligning fra head to head mellem Git ReBase vs Merge (Infographics)
Nedenfor er de top 5 sammenligninger mellem Git ReBase vs Merge:
De vigtigste forskelle mellem Git ReBase vs Merge
Lad os diskutere den vigtigste forskel mellem Git ReBase vs Merge:
1. Git rebase
Git Rebase begynder sit arbejde fra et fælles engagement mellem de to grene. Master og funktion, herfra sammenligner de begge og fanger snapshot af forskellen, der gøres i en af grenene, og tilføjer den derefter til andre. Lad os se på dette med nedenstående skærmbilleder.
Lad os forestille os, at vi har en mastergren og senest forpligter os til det m2 som vist på ovenstående skærmbillede. Fra denne engagement opretter vi en funktionsgren, og vi udførte nogle ændringer og forpligtede med f1-meddelelse. Lad os nu overveje, at nogen har fusioneret sit arbejde til at mestre, og nu er masterens seneste engagement m3, ikke m2, som vist nedenfor.
Og vi fortsætter også med at arbejde på funktionsgrenen for at tilføje dens seneste forpligtelse til at være f2 som vist nedenfor.
Som set ovenfra har vi screengrab mestret den seneste commit m3, og vi har en funktion, der ikke er opdateret med masteren, da den blev oprettet fra m2 commit snapshot, der har den nyeste commit som f3. Nu for at kombinere disse anstrengelser med masteren til at generere vises nedenfor.
Nu er vi nødt til at integrere ovenstående ændringer, der kan udføres på to måder, den ene med fusion og anden med rebase. Her skal vi se på, hvordan man integreres med rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Fra ovennævnte rebase-kommando vil vi forsøge at kigge efter et fælles engagement fra både master og funktion, og i dette tilfælde er det m2. Og da vi er nødt til at omklassificere master, vil det se efter tilføjelser, der blev udført med master og tage snapshot m3 og rebase-funktion fra m2 til m3. Så nu har vi en funktion med m3 (i stedet for m2), f1, f2 forpligter. Nu kan jeg ansøge om rebase på funktionen for at gøre mastergrenen opdateret med funktionsændringerne. Én ting at huske er enhver ændring af master skal revideres. Her viser jeg bare et eksempel.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Nu i dette vil vi anvende den nyeste engagementsfunktionsgren, der er f2 til at mestre, og den seneste begå et snapshot af masteren vil være f2. Du kan liste over forpligtelserne ved hjælp af kommando med git-log, men vi skal først tjekke, hvilken gren vi har brug for for at se loggen som nedenfor.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Nu med rebase har vi integreret opdateringerne af en funktion, der skal masteres. Lad os prøve at opnå dette ved at fusionere.
2. Git Merge
Vi vil også bruge ovenstående skærmbillede til reference her, og vi kan også opnå det samme, som vi opnåede med rebase og merge.
Git merge forpligter det sidste engagement, som vi havde i funktionsgrenen, og her er tilfældet med f2 commit, som samler alle ændringerne og fusionerer det med det seneste engagement, som vi har i mastergrenen, m3 her. Dette ser kompliceret ud, men kan let udføres med kommandoen fletning. Vi kan enten udføre en direkte fletning eller squashfusion og forskellen i begge dele.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Ovenstående kommando tager alle forpligtelser med funktionen og tilføjer også masterens log. For at undgå, at vi kan bruge squash, så i masterens log vil vi efter m3 kun have en engagement, og det er opdatering
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
man skal være forsigtig, mens man bruger git rebase og forsøge at undgå det. Den gyldne regel er at undgå, at der bruges offentlige filialer.
Bare se på ovenstående scenarie. Dette kan ske, når du prøver at omlægge master oven på din funktionsgren, og vores mastergren er offentlig, nu er mastergrenen opdateret, men alle andre arbejder på en ældre version af master. Da rebasing vil resultere i helt nye forpligtelser, kan git tænke, at mestergrenens historie er forskellig fra alle andre. Den eneste måde at løse dette på er at synkronisere både masteren ved at slå dem sammen igen og have et resulterende sæt af forpligtelser, der vil være forvirrende.
Sammenligningstabel over Git ReBase vs Merge
Tabellen nedenfor opsummerer sammenligningerne mellem Git ReBase vs Merge:
| Grundlag for sammenligning mellem Rebase vs Merge | Rebase | Fusionere |
| begår | Det ændrer og omskriver historikken ved at oprette en ny forpligtelse for hver begå i kildegrenen. | Det inkorporerer alle ændringerne til kilden, men opretholder stamtavlen til hver begivenhedshistorie inkorporerer alle ændringerne til kilden, men opretholder anerne til hver begåhistorik. |
| Udvælgelse | Her tjekker vi først den gren, der skal ombaseres, og vælg derefter rebase-kommandoen at tilføje det opdateringer til andre. | Her skal du først tjekke den gren, der skal flettes først. Derefter udfør kildens fletningsoperation og den nyeste engagement vil blive fusioneret med mesterskabets sidste engagement. |
| Konflikthåndtering | Da forpligtelseshistorik vil blive omskrevet for at forstå konflikten, vil det være vanskeligt i nogle tilfælde. | Flettekonflikt kan let håndteres ved at forstå den fejl, der blev udført under fusionen. |
| gylden regel | Skulle man bruge dem på de offentlige filialer, siden begå historie, kan forårsage forvirring. | Ikke meget skade, mens du udfører offentlige filialer. |
| Sikring af adgang | Forpligtelser, der engang var tilgængelige, kan ikke længere nås efter rebase, da forpligtelseshistorik ændres. | Forpligtelser vil fortsat være tilgængelige fra kildegrenerne. |
Konklusion
Fletning og rebase er et par to kraftfulde værktøjer fra Git, og begge bruges til at integrere ændringerne i grenene, men vi må være lidt forsigtige med rebase, da det vil omskrive historien med forpligtelser og at bruge dem på offentlige grene kan hæmme arbejdet af andre, der forårsager dem forvirring. Mens du kan bruge fusionsindstillingen, da dens forpligtelser kan nås fra kildegrenen og let kan løse flette konflikter, hvis vi har korrekt forståelse.
Anbefalede artikler
Dette er en guide til den største forskel mellem Git ReBase vs Merge. Her diskuterer vi også Git ReBase vs Merge nøgleforskelle med infografik og sammenligningstabel. Du kan også se på de følgende artikler for at lære mere -
- Git Fetch vs Git Pull - Topforskelle
- Abstraktion vs indkapsling | Top 6 sammenligning
- HBase Arkitektur med fordele
- GIT Interview spørgsmål | Top 11
- GIT versionskontrolsystem
- Git Push
- Indkapsling i JavaScript
- Komplet guide til Git-fjernkommando
- Tre faser af Git-livscyklus med arbejdsgangen
- Hvordan bruges GIT Cherry-pick med eksempel?