Skillnaden mellan Git ReBase vs Merge
I den här artikeln kommer vi att diskutera två sådana verktyg Rebase and Merge och deras skillnad. GIT är en av de mest använda distribuerade versionskontrollern DVCS bland programmerarna på grund av dess dynamiska natur och stora verktygstillgänglighet för att hantera versionerna. Det finns två sätt som vi kan skicka våra förändringar från en gren till en annan. Den ena är med hjälp av Rebase och den andra är Merge som är ganska populär. Nedan lär vi oss den bästa jämförelsen mellan Git ReBase vs Merge.
Jämförelse mellan head och head mellan Git ReBase vs Merge (Infographics)
Nedan visas de 5 bästa jämförelserna mellan Git ReBase vs Merge:
Viktiga skillnader mellan Git ReBase vs Merge
Låt oss diskutera den viktigaste skillnaden mellan Git ReBase vs Merge:
1. Git Rebase
Git Rebase inleder sitt arbete från ett gemensamt engagemang mellan de två grenarna. Mästare och funktion, härifrån jämför det båda och fångar ögonblicksbilden av skillnaden som görs i en av grenarna och lägger den sedan till andra. Låt oss titta på detta med nedanstående skärmdumpar.
Låt oss föreställa oss att vi har en huvudgren och senast förbinder oss till det m2 som visas i bildskärmen ovan. Från denna åtagande skapar vi en funktionsgren och vi gjorde några ändringar och begick med f1-meddelande. Låt oss nu tänka på att någon har släppt sitt arbete för att behärska och nu är den senaste åtaganden från befälhavaren m3, inte m2 som visas nedan.
Och vi fortsätter också att arbeta med funktionsgrenen för att lägga till det senaste åtagandet att vara f2 som visas nedan.
Som sett ovan är screengrab, vi har behärskat den senaste commit m3 och vi har en funktion som inte är uppdaterad med master eftersom den skapades från m2 commit-snapshot som har den senaste commit som f3. Nu för att kombinera dessa ansträngningar med master att generera visas nedan.
Nu måste vi integrera ovanstående förändringar, som kan göras på två sätt, ett med sammanslagning och andra med rebase. Här kommer vi att titta på hur man integrerar med rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Från ovannämnda rebase-kommando kommer vi att försöka leta efter ett vanligt engagemang från både master och funktion och i detta fall är det m2. Och sedan vi måste ombasera master kommer det att leta efter tillägg som gjordes med master och ta snapshot m3 och rebase-funktionen från m2 till m3. Så nu har vi en funktion med m3 (i stället för m2), f1, f2 åtaganden. Nu kan jag ansöka om omfasning av funktionen för att göra mastergrenen uppdaterad med funktionsändringarna. En sak att komma ihåg är att alla ändringar i master måste granskas. Här visar jag bara ett exempel.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Nu i detta kommer vi att tillämpa den senaste åtagandefunktionsgrenen som är f2 för att behärska och den senaste åtagandebilden för befälhavaren är f2. Du kan ange åtaganden med hjälp av git-loggkommando men vi måste först kolla in vilken gren vi behöver för att se loggen nedan.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Nu med rebase har vi integrerat uppdateringarna av en funktion att behärska. Låt oss försöka uppnå detta genom att slå samman.
2. Git Merge
Vi kommer att använda ovanstående skärmdump för referensen här också, och vi kan uppnå samma sak som vi uppnådde med rebase och sammanslagning också.
Git-merge förbinder det senaste åtagandet som vi hade i funktionsgrenen och här är fallet med f2-åtagandet, som samlar alla förändringar och sammanfogar det med det senaste åtagandet som vi har i mastergrenen, m3 här. Det här ser komplicerat ut men kan enkelt utföras med kommandot sammanslagning. Vi kan antingen göra en direkt sammanslagning eller squashfusion och skillnaden i båda.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Ovanstående kommando tar alla funktionsåtgärder och lägger till i masterens logg också. För att undvika att vi kan använda squash så att vi i mesterens logg bara efter en m3 kommer att göra en uppdatering och det är av uppdatering
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
man bör vara försiktig när man använder git rebase och försöker undvika det. Den gyllene regeln är att undvika att använda offentliga filialer.
Titta bara på ovanstående scenario. Det här kan hända när du försöker återföra master ovanför din funktionsgren och vår mastergren är offentlig, nu är mastergrenen uppdaterad men alla andra arbetar på en äldre version av master. Eftersom omplacering kommer att resultera i helt nya åtaganden kan git tänka att historia för mästarkontoret har avvikit från alla andra. Det enda sättet att lösa detta är att synkronisera både master genom att slå dem samman igen och ha en resulterande uppsättning av åtaganden som kommer att vara förvirrande.
Jämförelsetabell för Git ReBase vs Merge
Tabellen nedan sammanfattar jämförelserna mellan Git ReBase vs Merge:
| Grund för jämförelse mellan Rebase vs Merge | Rebase | Sammanfoga |
| Begår | Det ändrar och skriver om historiken genom att skapa ett nytt engagemang för varje åtagande i källgrenen. | Den innehåller alla ändringar i källan men upprätthåller förfäder till varje begåvningshistorik och innehåller alla ändringar i källan men upprätthåller förfäder till varje begåvningshistorik. |
| Urval | Här kontrollerar vi först grenen som behöver ombaseras och välj sedan kommandot rebase för att lägga till uppdateringar till andra. | Här ska du först kolla in den gren som måste slås samman först. Utför sedan källans sammanslagningsoperation och senaste åtagande kommer att slås samman med befälhavarens senaste åtagande. |
| Konflikthantering | Eftersom begåvningshistorik kommer att skrivas om för att förstå konflikten kommer att vara svårt i vissa fall. | Sammanslagningskonflikt kan enkelt hanteras för att förstå det misstag som utfördes vid sammanslagning. |
| gyllene regel | Bör använda på de offentliga filialerna sedan begå historia kan orsaka förvirring. | Ingen stor skada när du utför offentliga filialer. |
| Nåbarhet | Åtaganden som en gång var nåbara kommer inte längre att kunna nås efter rebas eftersom engagemangshistoriken ändras. | Åtaganden kommer att förbli nås från källgrenarna. |
Slutsats
Merge and Rebase är ett par av två kraftfulla verktyg från Git och båda används för att integrera förändringarna i grenarna, men vi måste vara lite försiktiga med rebase eftersom det kommer att skriva om historien om åtaganden och att använda dem på offentliga grenar kan hindra arbetet av andra orsakar dem förvirring. Medan du kan använda fusionsalternativet eftersom dess åtaganden kan nås från källgrenen och lätt kan lösa sammanslagningskonflikter om vi har rätt förståelse.
Rekommenderade artiklar
Detta är en guide till den bästa skillnaden mellan Git ReBase vs Merge. Här diskuterar vi också Git ReBase vs Merge viktiga skillnader med infografik och jämförelsetabell. Du kan också titta på följande artiklar för att lära dig mer -
- Git Fetch vs Git Pull - Top Differences
- Abstraktion vs inkapsling | Topp 6 jämförelse
- HBase Arkitektur med fördelar
- GIT intervjufrågor | Topp 11
- GIT-versionskontrollsystem
- Git Push
- Inkapsling i JavaScript
- Komplett guide till Git-fjärrkommando
- Tre steg av Git-livscykel med arbetsflödet
- Hur använder jag GIT Cherry-pick med exempel?