door Vali Shah

als ontwikkelaar moeten velen van ons kiezen tussen Merge en Rebase. Met alle referenties die we krijgen van het internet, iedereen gelooft “gebruik Rebase niet, het kan ernstige problemen veroorzaken.”Hier zal ik uitleggen wat merge en rebase zijn, waarom je ze moet (en niet) gebruiken, en hoe dat te doen.

Git Merge en Git Rebase dienen hetzelfde doel. Ze zijn ontworpen om veranderingen van meerdere branches in één te integreren., Hoewel het uiteindelijke doel is hetzelfde, die twee methoden te bereiken op verschillende manieren, en het is handig om het verschil te weten als je een betere software-ontwikkelaar.

deze vraag heeft de git gemeenschap gesplitst. Sommigen geloven dat je altijd moet rebasen en anderen dat je altijd moet mergen. Elke kant heeft een aantal overtuigende voordelen.

Git Merge

mergen is een gangbare praktijk voor ontwikkelaars die versiebeheersystemen gebruiken. Of branches gemaakt worden voor testen, bugfixes, of andere redenen, het mergen van commits verandert naar een andere locatie., Om specifieker te zijn, mergen neemt de inhoud van een bron branch en integreert ze met een doel branch. In dit proces wordt alleen de doel branch gewijzigd. De bron branch geschiedenis blijft hetzelfde.,da2a4595a”>

Samenvoegen Master -> ‘ Feature branch

Pluspunten

  • Eenvoudig en vertrouwd
  • Behoudt volledige geschiedenis en chronologische volgorde
  • Onderhoudt de context van de branch

Nadelen

  • Commit geschiedenis kan verontreinigd zijn door veel samenvoegen pleegt
  • Foutopsporing met behulp van git bisect kunnen moeilijker worden

Hoe om het te doen

het Samenvoegen van de master branch in de ‘feature branch’ met behulp van de checkout en merge commando ‘ s.,

$ git checkout feature$ git merge master(or)$ git merge master feature

Dit zal een nieuwe” Merge commit ” aanmaken in de feature branch die de geschiedenis van beide branches bevat.

Git Rebase

Rebase is een andere manier om veranderingen van de ene branch naar de andere te integreren. Rebase comprimeert alle veranderingen in een enkele ” patch.”Dan integreert het de patch op de target branch.

In tegenstelling tot mergen, maakt rebasen de geschiedenis plat omdat het het voltooide werk van de ene branch naar de andere overbrengt. In het proces, ongewenste geschiedenis wordt geëlimineerd.,

Rebases worden hoe de veranderingen moet passeren van de top van de hiërarchie naar beneden, en samenvoegingen zijn hoe ze vloeien terug naar boven

Rebase functie in je master branch

Pluspunten

  • Stroomlijnt een mogelijk complexe geschiedenis
  • het bewerken van een enkele commit is eenvoudig (bijv., ze terugdraaien)
  • vermijdt merge commit “ruis” in drukke repo ‘ s met drukke branches
  • reinigt intermediaire commits door ze een enkele commit te maken, wat nuttig kan zijn voor DevOps-teams

Cons

  • Squashing the feature down to a handvol commits can hide the context
  • Rebasen public repositories kan gevaarlijk zijn bij het werken als een team
  • Het is meer werk: rebase gebruiken om je feature branch altijd bijgewerkt te houden vereist
  • rebasen met remote branches dat je push forceert., Het grootste probleem waar mensen mee te maken hebben is dat ze push forceren, maar git push standaard niet hebben ingesteld. Dit resulteert in updates voor alle branches met dezelfde naam, zowel lokaal als op afstand, en dat is verschrikkelijk om mee om te gaan.

Als u de geschiedenis onjuist rebase en onbedoeld herschrijft, kan dit tot ernstige problemen leiden, dus zorg ervoor dat u weet wat u doet!

hoe dit te doen

Rebase de feature branch op de master branch met behulp van de volgende commando ‘ s.,

$ git checkout feature$ git rebase master

Dit verplaatst de gehele feature branch bovenop de master branch. Het doet dit door de projectgeschiedenis opnieuw te schrijven door gloednieuwe commits te maken voor elke commit in de originele (feature) branch.

interactief Rebasen

Dit maakt het mogelijk de commits te wijzigen als ze naar de nieuwe branch worden verplaatst. Dit is krachtiger dan geautomatiseerde rebase, omdat het volledige controle biedt over de commit historie van de branch. Meestal wordt dit gebruikt om een rommelige geschiedenis op te schonen voordat een feature branch in master wordt gemerged.,

$ git checkout feature$ git rebase -i master

Dit opent de editor door alle commits te tonen die op het punt staan te worden verplaatst.

pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

dit definieert precies hoe de branch eruit zal zien nadat de rebase is uitgevoerd. Door de entiteiten opnieuw te ordenen, kun je de geschiedenis laten lijken op wat je wilt. U kunt bijvoorbeeld opdrachten gebruiken als fixup, squash, edit etc, in plaats van pick.

welke te gebruiken

dus wat is het beste?, Wat adviseren de experts?

Het is moeilijk om te generaliseren en te beslissen over het een of het ander, omdat elk team anders is. Maar we moeten ergens beginnen.

Teams moeten verschillende vragen overwegen bij het instellen van hun Git rebase vs.merge beleid. Want het blijkt dat de ene workflow strategie niet beter is dan de andere. Het is afhankelijk van uw team.

overweeg het niveau van rebasen en Git competentie in je organisatie. Bepaal in welke mate U waarde hecht aan de eenvoud van rebasen in vergelijking met de traceerbaarheid en geschiedenis van het samenvoegen.,

ten slotte moeten beslissingen over mergen en rebasen worden beschouwd in de context van een duidelijke branchingstrategie (zie dit artikel voor meer informatie over branchingstrategie). Een succesvolle branching strategie is ontworpen rond de organisatie van uw teams.

wat raad ik aan?

naarmate het team groeit, zal het moeilijk worden om ontwikkelingswijzigingen te beheren of te traceren met een altijd merge beleid. Om een schone en begrijpelijke commit geschiedenis te hebben, is het gebruik van Rebase redelijk en effectief.,

door rekening te houden met de volgende omstandigheden en richtlijnen, kunt u het beste uit Rebase halen:

  • u ontwikkelt lokaal: als u uw werk niet met iemand anders hebt gedeeld. Op dit punt zou je de voorkeur moeten geven aan rebasen boven mergen om je geschiedenis netjes te houden. Als je je persoonlijke fork van de repository hebt en die niet gedeeld wordt met andere ontwikkelaars, ben je veilig om te rebasen, zelfs nadat je naar je branch gepusht hebt.
  • je code is klaar voor beoordeling: Je hebt een pull request aangemaakt. Anderen beoordelen je werk en halen het mogelijk in hun fork voor lokale beoordeling., Op dit punt moet je je werk niet rebasen. Je zou ‘rework’ commits moeten maken en je feature branch moeten updaten. Dit helpt bij de traceerbaarheid in de pull request en voorkomt het per ongeluk breken van de geschiedenis.
  • de review is gedaan en klaar om te worden geà ntegreerd in de target branch. Gefeliciteerd! Je staat op het punt je feature branch te verwijderen. Gezien het feit dat andere ontwikkelaars deze wijzigingen vanaf dit moment niet zullen fetch-mergen, is dit uw kans om uw geschiedenis te saniteren., Op dit punt kun je de geschiedenis herschrijven en de originele commits en die vervelende ‘pr rework’ en ‘merge’ commits folden in een kleine set van gefocuste commits. Het maken van een expliciete merge voor deze commits is optioneel, maar heeft waarde. Het registreert wanneer de functie afgestudeerd aan de meester.

conclusie

Ik hoop dat deze uitleg wat inzichten heeft gegeven over Git merge en Git rebase. Merge vs rebase strategie is altijd discutabel. Maar misschien zal dit artikel helpen verdrijven uw twijfels en kunt u een aanpak die werkt voor uw team te nemen.