Verschil tussen Git ReBase versus Merge
In dit artikel bespreken we twee van dergelijke tools Rebase en Merge en hun verschil. GIT is een van de meest gebruikte gedistribueerde versiecontroller DVCS onder de programmeurs vanwege het dynamische karakter en de enorme beschikbaarheid van tools om de versies te verwerken. Er zijn twee manieren waarmee we onze wijzigingen van de ene tak naar de andere kunnen verzenden. De ene is door Rebase te gebruiken en de andere is Merge, die behoorlijk populair is. Hieronder leren we de beste vergelijking tussen Git ReBase vs Merge.
Head to Head-vergelijking tussen Git ReBase vs Merge (Infographics)
Hieronder staan de top 5 vergelijkingen tussen Git ReBase vs Merge:
Belangrijkste verschillen tussen Git ReBase versus Merge
Laten we het belangrijkste verschil bespreken tussen Git ReBase versus Merge:
1. Git Rebase
Git Rebase begint zijn werk vanuit een gemeenschappelijke commit tussen de twee takken. Master en feature, vanaf hier vergelijkt het beide en legt het de momentopname vast van het verschil dat in een van de branches wordt gedaan en voegt het vervolgens toe aan anderen. Laten we dit eens bekijken met de onderstaande screenshots.
Laten we ons voorstellen dat we een master branch hebben en de laatste commit eraan m2 zoals getoond in de bovenstaande screenshot. Van deze commit maken we een feature branch en hebben we enkele aanpassingen gedaan en commit met f1 bericht. Laten we nu eens overwegen dat iemand zijn werk heeft samengevoegd om te beheersen en nu is de laatste commit van de master m3, niet m2 zoals hieronder getoond.
En we blijven ook werken aan de functietak om de laatste commit toe te voegen aan f2 zoals hieronder getoond.
Zoals te zien van bovenstaande screengrab, hebben we de nieuwste commit m3 onder de knie en we hebben een functie die niet up-to-date is met de master omdat deze is gemaakt op basis van m2 commit snapshot met de nieuwste commit als f3. Nu om deze inspanningen te combineren met de te genereren master wordt hieronder getoond.
Nu moeten we de bovenstaande wijzigingen integreren die op twee manieren kunnen worden gedaan: één met samenvoegen en één met rebase. Hier zullen we kijken hoe te integreren met rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Met de bovenstaande rebase-opdracht zullen we proberen te zoeken naar een gemeenschappelijke commit van zowel master als feature en in dit geval is dit m2. En dan, omdat we master moeten rebasen, zal het zoeken naar toevoegingen die zijn gedaan met master en snapshot m3 en rebase-functie nemen van m2 tot m3. Dus nu hebben we een functie met m3 (in plaats van m2), f1, f2 commits. Nu kan ik een aanvraag indienen om de functie opnieuw op te starten om de hoofdtak te laten bijwerken met de functiewijzigingen. Een ding om te onthouden is dat elke verandering die u moet beheersen moet worden gecontroleerd. Hier laat ik alleen een voorbeeld zien.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Hierin zullen we de nieuwste commit-functietak toepassen die f2 is op master en de laatste commit snapshot van de master zal f2 zijn. Je kunt de commits weergeven met de opdracht git log, maar we moeten eerst kijken naar welke branch we het logboek moeten zien, zoals hieronder.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Nu met rebase hebben we de updates geïntegreerd van een te beheersen functie. Laten we proberen dit te bereiken door samen te voegen.
2. Git samenvoegen
We zullen de bovenstaande screenshot ook hier gebruiken voor de referentie, en we kunnen hetzelfde bereiken als we hebben bereikt met rebase en merge.
Git merge commits de laatste commit die we hadden in de feature branch en hier is het geval met f2 commit, die alle veranderingen verzamelt en samenvoegt met de laatste commit die we hebben in de master branch, m3 hier. Dit ziet er ingewikkeld uit maar kan eenvoudig worden uitgevoerd met de opdracht merge. We kunnen een directe samenvoeging of squash samenvoegen en het verschil in beide.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
De bovenstaande opdracht neemt alle commits van de functie en voegt ook het logboek van de master toe. Om te voorkomen dat we squash kunnen gebruiken zodat we in het logboek van de master na m3 slechts één commit doorvoeren en dat is van update
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
men moet voorzichtig zijn tijdens het gebruik van git rebase en proberen het te vermijden. De gouden regel is om te voorkomen dat het openbare takken gebruikt.
Kijk maar naar het bovenstaande scenario. Dit kan gebeuren wanneer u master bovenop uw functietak probeert te rebasen en onze master branch openbaar is, nu wordt de master branch bijgewerkt maar werkt iedereen aan een oudere versie van master. Omdat rebasen zal resulteren in gloednieuwe commits, kan git denken dat de geschiedenis van de master branch van iedereen is afgeweken. De enige manier om dit op te lossen, is om de master te synchroniseren door ze weer samen te voegen en een resulterende set commits te hebben die verwarrend kunnen zijn.
Vergelijkingstabel van Git ReBase vs Merge
De onderstaande tabel vat de vergelijkingen tussen Git ReBase en Merge samen:
| Vergelijkingsbasis tussen Rebase versus Merge | rebase | Samenvoegen |
| commits | Het verandert en herschrijft de geschiedenis door een nieuwe commit te maken voor elke commit in de source branch. | Het bevat alle wijzigingen in de bron, maar onderhoudt afstamming van elke vastleggingsgeschiedenis bevat alle wijzigingen in de bron, maar handhaaft afstamming van elke vastleggingsgeschiedenis. |
| Selectie | Hier kijken we eerst naar de branch die opnieuw moet worden geboot en selecteer vervolgens de opdracht rebase om updates aan anderen toe te voegen. | Bekijk hier eerst de branch die eerst moet worden samengevoegd. Voer vervolgens de samenvoegbewerking en de laatste commit van de bron uit zal worden samengevoegd met de laatste commit van de master. |
| Conflictafhandeling | Omdat commit geschiedenis zal worden herschreven om te begrijpen dat het conflict moeilijk zal zijn sommige gevallen. | Samenvoegconflicten kunnen gemakkelijk worden afgehandeld met begrip van de fout die is gemaakt tijdens het samenvoegen. |
| gouden regel | Moet worden gebruikt op de openbare filialen, omdat de geschiedenis van commit verwarring kan veroorzaken. | Niet veel kwaad tijdens het uitvoeren van openbare vestigingen. |
| bereikbaarheid | Commits die ooit bereikbaar waren, zijn na rebase niet meer bereikbaar omdat de commit-geschiedenis is gewijzigd. | Commits blijven bereikbaar van de bron takken. |
Conclusie
Merge en Rebase zijn een paar twee krachtige tools van Git en beide worden gebruikt om de wijzigingen in de branches op te nemen, maar we moeten een beetje voorzichtig zijn met rebase omdat het de geschiedenis van commits herschrijft en het gebruik ervan op openbare branches het werk kan belemmeren van anderen veroorzaken verwarring. Terwijl je de merge-optie kunt gebruiken omdat de commits bereikbaar zijn vanuit de source branch en gemakkelijk merge-conflicten kunnen oplossen als we het goed begrijpen.
Aanbevolen artikelen
Dit is een gids voor het grootste verschil tussen Git ReBase versus Merge. Hier bespreken we ook de belangrijkste verschillen tussen Git ReBase en Merge met infographics en vergelijkingstabel. U kunt ook de volgende artikelen bekijken voor meer informatie -
- Git Fetch vs Git Pull - Topverschillen
- Abstractie versus inkapseling | Top 6 vergelijking
- HBase-architectuur met voordelen
- Vragen tijdens solliciteren bij GIT | Top 11
- GIT-versiebeheersysteem
- Git Push
- Inkapseling in JavaScript
- Complete gids voor Git remote Command
- Drie fasen van Git-levenscyclus met de workflow
- Hoe GIT Cherry-pick met Voorbeeld te gebruiken?