Forskjellen mellom Git ReBase vs Merge
I denne artikkelen skal vi diskutere to slike verktøy Rebase and Merge og deres forskjell. GIT er en av de mest brukte distribuerte versjonskontroller DVCS blant programmererne på grunn av sin dynamiske natur og enorme verktøytilgjengelighet for å håndtere versjonene. Det er to måter vi kan sende endringene på fra en gren til en annen. Den ene er ved å bruke Rebase og den andre er Merge som er ganske populær. Nedenfor lærer vi den beste sammenligningen mellom Git ReBase vs Merge.
Sammenligning fra topp til hodet mellom Git ReBase vs Merge (Infographics)
Nedenfor er de 5 beste sammenligningene mellom Git ReBase vs Merge:
Viktige forskjeller mellom Git ReBase vs Merge
La oss diskutere den viktigste forskjellen mellom Git ReBase vs Merge:
1. Git Rebase
Git Rebase begynner arbeidet sitt fra en felles forpliktelse mellom de to grenene. Master og funksjon, herfra sammenligner de begge og fanger øyeblikksbildet av forskjellen som gjøres i en av grenene, og legger den deretter til andre. La oss se på dette med skjermbildene nedenfor.
La oss forestille oss at vi har en hovedfilial og nyeste forpliktelse til den m2 som vist på skjermbildet ovenfor. Fra denne forpliktelsen oppretter vi en funksjonsgren og vi gjorde noen endringer og forpliktet med f1-melding. La oss nå se på at noen har slått sammen arbeidet sitt for å mestre, og nå er mesteren av den siste oppgaven m3, ikke m2 som vist nedenfor.
Og vi fortsetter også å jobbe med funksjonsgrenen for å legge til den siste forpliktelsen til å være f2 som vist nedenfor.
Som sett ovenfra har screengrab behersket den siste commit m3 og vi har en funksjon som ikke er oppdatert med masteren da den ble opprettet fra m2 commit snapshot som har den siste commit som f3. Nå for å kombinere denne innsatsen med mesteren å generere er vist nedenfor.
Nå må vi integrere de ovennevnte endringene som kan gjøres på to måter, den ene med sammenslåing og den andre med rebase. Her skal vi se på hvordan vi kan integrere med rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Fra ovennevnte rebase-kommando vil vi prøve å se etter en vanlig forpliktelse fra både master og funksjon, og i dette tilfellet er det m2. Og siden vi må ombasere master, vil den se etter tillegg som ble gjort med master og ta stillbilde m3 og rebase-funksjon fra m2 til m3. Så nå har vi en funksjon med m3 (i stedet for m2), f1, f2 forplikter. Nå kan jeg søke om omfase på funksjonen for å gjøre mastergrenen oppdatert med funksjonsendringene. Én ting å huske er enhver endring av master må revideres. Her viser jeg bare for eksempel formål.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Nå i dette vil vi bruke den nyeste engasjementsfunksjonsgrenen som er f2 for å mestre, og den siste forpliktelsesbildet av masteren vil være f2. Du kan liste opp forpliktelsene ved å bruke git-logg-kommandoen, men vi må først sjekke ut hvilken gren vi trenger for å se loggen som nedenfor.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Nå med omfase har vi integrert oppdateringene av en funksjon som skal mestres. La oss prøve å oppnå dette ved å slå sammen.
2. Git Merge
Vi vil bruke skjermbildet ovenfor for referanse også her, og vi kan oppnå det samme som vi oppnådde med omfase og sammenslåing også.
Git merge forplikter den siste forpliktelsen som vi hadde i funksjonen grenen, og her er saken med f2 commit, som samler alle endringene og fusjonerer den med den siste forpliktelsen som vi har i mastergrenen, m3 her. Dette ser komplisert ut, men kan enkelt utføres av flettekommandoen. Vi kan enten gjøre en direkte sammenslåing eller squashfusjon og forskjellen i begge deler.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Kommandoen ovenfor vil ta alle forpliktelsene til funksjonen og legge til i loggen til masteren også. For å unngå at vi kan bruke squash, slik at vi i mesterens logg kun vil ha en engasjement, og det er oppdatering
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
man bør være forsiktig mens man bruker git rebase og prøver å unngå det. Den gylne regelen er å unngå at den bruker offentlige grener.
Bare se på scenariet ovenfor. Dette kan skje når du prøver å resase master på toppen av funksjonsgrenen og mastergrenen vår er offentlig, nå er mastergrenen oppdatert, men alle andre jobber med en eldre versjon av master. Siden omfasing vil føre til helt nye forpliktelser, kan git tenke at historien til mestergrenen har avviket fra alle andre. Den eneste måten å løse dette på vil være å synkronisere både masteren ved å slå dem sammen igjen og ha et resulterende sett med forpliktelser som vil være forvirrende.
Sammenligningstabell over Git ReBase vs Merge
Tabellen nedenfor oppsummerer sammenligningene mellom Git ReBase vs Merge:
| Grunnlag for sammenligning mellom Rebase vs Merge | Rebase | Slå sammen |
| inger | Det endrer og omskriver historikken ved å opprette en ny forpliktelse for hver forpliktelse i kildegrenen. | Den inneholder alle endringene i kilden, men opprettholder aner i hver begivenhetshistorie og inneholder alle endringene i kilden, men opprettholder aner til hver begårhistorie. |
| utvalg | Her skal vi først sjekke ut grenen som må omfases, og velg deretter rebase-kommandoen for å legge den til andre. | Her sjekker du først grenen som må slås sammen først. Deretter utfører du fletteoperasjonen og den nyeste kilden vil bli slått sammen med den nyeste forpliktelsen fra mesteren. |
| Konflikthåndtering | Siden forpliktelseshistorien vil bli skrevet om for å forstå konflikten vil være vanskelig i noen tilfeller. | Fusjonskonflikt kan enkelt håndteres for å forstå feilen som ble utført under sammenslåing. |
| den gyldne regel | Skal brukes på offentlige filialer siden forpliktelse historie kan forårsake forvirring. | Ikke mye skade mens du utfører offentlige grener. |
| reachability | Forpliktelser som en gang var tilgjengelig, vil ikke lenger kunne nås etter rebase siden forpliktelseshistorien er endret. | Forpliktelser vil forbli tilgjengelige fra kildegrenene. |
Konklusjon
Merge and Rebase er et par av to kraftige verktøy fra Git, og begge brukes til å innlemme endringene i grenene, men vi må være litt forsiktige med rebase siden det vil omskrive historien til forpliktelser og å bruke dem på offentlige grener kan hemme arbeidet av andre forårsaker forvirring. Mens du kan bruke fusjonsalternativet ettersom forpliktelsene kan nås fra kildegrenen og lett kan løse flette konflikter hvis vi har god forståelse.
Anbefalte artikler
Dette er en guide til toppforskjellen mellom Git ReBase vs Merge. Her diskuterer vi også Git ReBase vs Merge viktige forskjeller med infografikk og sammenligningstabell. Du kan også se på følgende artikler for å lære mer -
- Git Fetch vs Git Pull - Topp forskjeller
- Abstraksjon vs innkapsling | Topp 6 sammenligning
- HBase Arkitektur med fordeler
- Spørsmål om GIT-intervju | Topp 11
- GIT versjonskontrollsystem
- Git Push
- Innkapsling i JavaScript
- Komplett guide til Git-fjernkommando
- Tre stadier av Git-livssyklus med arbeidsflyten
- Hvordan bruker jeg GIT Cherry-pick med eksempel?