De Git rebase commando combineert twee broncodetakken tot één. De Git merge commando doet dat ook. Wij leggen uit wat rebase doet, hoe het wordt gebruikt en wanneer te gebruiken merge in plaats daarvan.
De Git-explosie
Wat is Git-merge?
Wat is Git-rebase?
Hoe te rebaseen op een andere tak
Git Rebase vs. Merge: welke moet je gebruiken?
Rebaseen of niet rebaseen?
De Git-explosie
Gefrustreerd door andere versiebeheersystemen en hun trage updates en commits, legde Linus Torvalds, bekend van de Linux-kernel, in 2005 een maand opzij om zijn eigen versie te schrijven. Hij noemde het Git.
Sites zoals GitHub, GitLab en BitBucket hebben symbiotisch gepromoot en geprofiteerd van Git. Tegenwoordig wordt Git wereldwijd gebruikt, met maar liefst 98 procent van de 71.000 respondenten in een onderzoek uit 2022 dat Git als versiebeheersysteem gebruikt.
Een van de belangrijkste ontwerpbeslissingen van Git was snelheid. Vooral het werken met filialen moest zo snel mogelijk. Branches zijn een fundamenteel onderdeel van versiebeheersystemen. Een projectrepository zal een main- of master-branch hebben. Dit is waar de codebasis van het project zich bevindt. Ontwikkeling, zoals nieuwe features, vindt plaats in gescheiden zijtakken. Dit voorkomt dat het werk dat in branches wordt gedaan de master branch in de war brengt, en het maakt gelijktijdige ontwikkeling mogelijk in verschillende delen van de codebase.
Wanneer de ontwikkelingen in de zijtakken zijn voltooid, worden de wijzigingen overgebracht naar de hoofdtak door de ontwikkelingstak samen te voegen met de hoofdtak. In andere versies was het werken met filialen van controlesystemen moeilijk en rekenkundig duur. Werken met branches in Git is erg snel en erg licht van gewicht. Wat ooit een saaie en vaak vermeden oefening was in andere systemen, werd triviaal in Git.
De Git rebase commando is een andere manier om de wijzigingen van de ene tak naar een andere tak over te brengen. De merge en rebase commando’s hebben vergelijkbare doelen, maar ze bereiken hun doelen op verschillende manieren en leveren iets andere resultaten op.
Wat is Git-merge?
Dus wat is de Git merge opdracht voor? Laten we zeggen dat je een branch hebt gemaakt met de naam dev-branch om aan een nieuwe functie te werken.
Je maakt een paar commits en test je nieuwe feature. Het werkt allemaal goed. Nu wilt u uw nieuwe functie naar de master tak. Je moet in de master branch om er een andere mee samen te voegen.
We kunnen ervoor zorgen dat we in de master branch door het expliciet uit te checken voordat we mergen.
git checkout master
We kunnen Git nu vertellen om de dev-branch in de huidige tak, dat is de master tak.
git merge dev-branch
Ons merge is voor ons klaar. Als u afrekent met de master branch en compileer het, het zal de nieuw ontwikkelde feature erin hebben. Wat Git feitelijk heeft uitgevoerd, is een samenvoeging in drie richtingen. het vergelijkt de meest recente commits in de master en dev-branch takken, en de commit in de master tak direct voor de dev-branch werd gecreëerd. Het voert dan een commit uit op de master tak.
Samenvoegingen worden als niet-destructief beschouwd omdat ze niets verwijderen en niets veranderen aan de geschiedenis van Git. De dev-branch bestaat nog steeds en geen van de vorige commits is gewijzigd. Er wordt een nieuwe commit gemaakt die de resultaten van de drievoudige samenvoeging vastlegt.
Na het samenvoegen ziet onze Git-repository eruit als een tijdlijn met een alternatieve lijn die aftakt en vervolgens terugkeert naar de hoofdtijdlijn.
De dev-branch tak is opgenomen in de master tak.
Als u veel branches in één project heeft, kan de geschiedenis van het project verwarrend worden. Dit is vaak het geval als een project veel bijdragers heeft. Omdat de ontwikkelingsinspanning zich opsplitst in veel verschillende paden, is de ontwikkelingsgeschiedenis niet-lineair. Het ontwarren van de commit-geschiedenis wordt nog moeilijker als branches hun eigen branches hebben.
Houd er rekening mee dat als u niet-vastgelegde wijzigingen in de master branch, moet je iets met deze wijzigingen doen voordat je er iets mee kunt samenvoegen. Je zou een nieuwe branch kunnen maken en de wijzigingen daar vastleggen, en dan de merge uitvoeren. Je zou dan je tijdelijke branch terug moeten mergen in de master branch.
Dat werkt, maar Git heeft een commando dat hetzelfde bereikt, zonder nieuwe branches te hoeven maken. De stash commando slaat uw niet-vastgelegde wijzigingen voor u op en laat u ze terugbellen met stash pop .
Je zou ze zo gebruiken:
stash git merge dev-branch stash pop
Het eindresultaat is een samengevoegde vertakking, waarbij uw niet-opgeslagen wijzigingen worden hersteld.
Wat is Git-rebase?
De Git rebase commando bereikt haar doelen op een geheel andere manier. Het neemt alle commits van de branch die je gaat rebaseen en speelt ze opnieuw af op het einde van de branch waarnaar je rebast.
Als we ons vorige voorbeeld nemen, ziet onze Git-repository er voordat we enige actie hebben uitgevoerd er zo uit. We hebben een filiaal genaamd dev-branch en we willen die wijzigingen verplaatsen naar de master tak.
Na de rebase ziet het eruit als een enkele, volledig lineaire tijdlijn van veranderingen.
De dev-branch is verwijderd, en de commits in de dev-branch zijn toegevoegd aan de hoofdtak. Het eindresultaat is hetzelfde als wanneer de commits in het dev-branch was eigenlijk direct toegewijd aan de master filiaal in de eerste plaats. De commits worden niet zomaar op de master branch, worden ze “opnieuw afgespeeld” en vers toegevoegd.
Dit is waarom de rebase commando wordt als destructief beschouwd. De rebased branch bestaat niet langer als een aparte branch, en de Git geschiedenis van je project is herschreven. Je kunt op een later tijdstip niet meer bepalen welke commits oorspronkelijk zijn gemaakt naar de dev-branch.
Het laat je echter achter met een vereenvoudigde, lineaire geschiedenis. Vergeleken met een repository met tientallen of zelfs honderden branches en samenvoegingen, het lezen van het Git-logboek of het gebruik van een grafische git GUI om naar een grafiek van de repository te kijken, is een rebased repository een koud kunstje om te begrijpen.
Hoe te rebaseen op een andere tak
Laten we eens proberen git rebase voorbeeld. We hebben een project met een filiaal genaamd new-feature. Wij zouden rebase die aftakking naar de master tak als deze.
Eerst controleren we of de master filiaal heeft geen uitstaande wijzigingen.
git status
We checken de new-feature tak.
git checkout new-feature
Dat zeggen we tegen Git rebase de huidige branch naar de master branch.
git rebase master
We zien dat we nog steeds twee vestigingen hebben.
git branch
We ruilen terug naar de master tak
git checkout master
We mergen de branch met nieuwe functies in de huidige branch, wat in ons geval de master tak.
git merge new-feature
Interessant genoeg hebben we nog steeds twee vestigingen na de definitieve samenvoeging.
Het verschil is, nu het hoofd van de new-feature tak en het hoofd van de master branch zijn ingesteld om naar dezelfde commit te verwijzen, en de geschiedenis van Git laat niet zien dat er vroeger een aparte was new-feature filiaal, afgezien van het filiaallabel.
Git Rebase vs. Merge: welke moet je gebruiken?
Het is geen geval van rebase tegen merge. Het zijn allebei krachtige commando’s en je zult ze waarschijnlijk allebei gebruiken. Dat gezegd hebbende, er zijn use-cases waar rebase werkt niet echt goed. Ongedaan maken van fouten veroorzaakt door fouten bij het gebruik merge zijn onaangenaam, maar losmaakfouten veroorzaakt door rebase is hels.
Als je de enige ontwikkelaar bent die een repository gebruikt, is de kans kleiner dat je er iets mee doet rebase dat is rampzalig. Je zou nog steeds kunnen rebase in de verkeerde richting bijvoorbeeld, en rebase je master branch naar je new-feature tak. Om je te krijgen master tak terug, zou je moeten rebase nogmaals, deze keer van uw new-feature filiaal naar uw master tak. Dat zou je herstellen master filiaal, zij het met een vreemd ogende geschiedenis.
Niet gebruiken rebase op gedeelde vestigingen waar anderen waarschijnlijk zullen werken. Uw wijzigingen in uw repository zullen voor veel mensen problemen veroorzaken wanneer u uw rebased code naar uw externe repository pusht.
Als uw project meerdere bijdragers heeft, is het veilig om alleen te gebruiken rebase op uw lokaal repository, en niet op openbare branches. Evenzo, als pull-aanvragen deel uitmaken van uw codebeoordelingen, gebruik deze dan niet rebase. Of in ieder geval niet gebruiken rebase na het maken van het pull-verzoek. Andere ontwikkelaars kijken waarschijnlijk naar je commits, wat betekent dat die veranderingen op een publieke branch zijn, zelfs als ze niet op de master tak.
Het gevaar is dat je gaat rebase commits die al naar een externe repository zijn gepusht, en andere ontwikkelaars hebben misschien al werk gebaseerd op die commits. Uw lokale rebase zal ervoor zorgen dat die bestaande commits verdwijnen. Als je die wijzigingen naar de repository pusht, zul je niet populair worden.
Andere bijdragers zullen door een puinhoop moeten gaan merge om hun werk terug naar de repository te krijgen. Als u vervolgens hun wijzigingen terughaalt naar uw lokale repository, wordt u geconfronteerd met het ongedaan maken van een puinhoop van gedupliceerde wijzigingen.
Rebaseen of niet rebaseen?
Rebase mogelijk verboden in uw project. Er kunnen lokale, culturele bezwaren zijn. Sommige projecten of organisaties overwegen rebase als een vorm van ketterij en een daad van ontheiliging. Sommige mensen geloven dat de geschiedenis van Git een onschendbaar, permanent verslag zou moeten zijn van wat er is gebeurd. Dus, rebase misschien van tafel.
Maar lokaal gebruikt, op particuliere vestigingen, rebase is een handig hulpmiddel.
Duw na je hebt gerebased, en beperk het tot branches waar je de enige ontwikkelaar bent. Of in ieder geval waar alle ontwikkeling is gestopt en niemand anders enig ander werk heeft gebaseerd op de commits van je branch.
Doe dat en je voorkomt problemen.