Rebasen is het proces van het verplaatsen of combineren van een reeks commits naar een nieuwe basis commit. Rebasen is het meest nuttig en gemakkelijk te visualiseren in de context van een functie branching workflow. Het algemene proces kan als volgt worden gevisualiseerd:

vanuit een contentperspectief verandert rebasen de basis van je branch van de ene commit naar de andere waardoor het lijkt alsof je je branch van een andere commit hebt gemaakt., Intern doet Git dit door nieuwe commits te maken en toe te passen op de opgegeven basis. Het is erg belangrijk om te begrijpen dat, ook al ziet de branch er hetzelfde uit, het bestaat uit geheel nieuwe commits.

gebruik

de primaire reden voor rebasen is om een lineaire projectgeschiedenis te behouden. Denk bijvoorbeeld aan een situatie waarin de master branch vooruitgang heeft geboekt sinds je begon te werken aan een feature branch., Je wilt de laatste updates van de master branch in je feature branch krijgen, maar je wilt de geschiedenis van je branch schoon houden zodat het lijkt alsof je met de laatste master branch hebt gewerkt. Dit geeft het latere voordeel van een schone merge van je feature branch terug naar de master branch. Waarom willen we een “schone geschiedenis”behouden? De voordelen van het hebben van een schone geschiedenis worden tastbaar bij het uitvoeren van Git operaties om de introductie van een regressie te onderzoeken. Een real-world scenario zou zijn:

1. Een bug wordt geïdentificeerd in de master branch., Een functie die succesvol werkte is nu gebroken.
2. een ontwikkelaar onderzoekt de geschiedenis van de master branch met behulp van git log vanwege de “clean history” kan de ontwikkelaar snel redeneren over de geschiedenis van het project.
3. de ontwikkelaar kan niet identificeren wanneer de bug werd geà ntroduceerd met git log dus voert de ontwikkelaar een git bisectuit.
4. omdat de git geschiedenis schoon is, heeft git bisect een verfijnde set commits om te vergelijken bij het zoeken naar de regressie., De ontwikkelaar vindt snel de commit die de bug introduceerde en is in staat om dienovereenkomstig te handelen.

leer meer over git log en Git bisect op hun individuele gebruikerspagina ‘ s.

je hebt twee opties om je functie te integreren in de master branch: direct mergen of rebasen en dan mergen. De eerste optie resulteert in een 3-weg merge en een merge commit, terwijl de laatste resulteert in een fast-forward merge en een perfect lineaire geschiedenis. Het volgende diagram laat zien hoe rebasen op de master branch een fast-forward merge faciliteert.,

Rebasen is een veelgebruikte manier om upstream wijzigingen in uw lokale repository te integreren. Het Pullen van upstream wijzigingen met Git merge resulteert in een overbodige merge commit elke keer dat je wilt zien hoe het project gevorderd is. Aan de andere kant is rebasen hetzelfde als zeggen: “Ik wil mijn veranderingen baseren op wat iedereen al gedaan heeft.”

rebase publieke geschiedenis

zoals we eerder hebben besproken in het herschrijven van de geschiedenis, zou je nooit commits moeten rebasen als ze naar een publieke repository zijn gepusht., De rebase zou de oude commits vervangen door nieuwe en het zou eruit zien alsof dat deel van je project Geschiedenis abrupt verdwenen is.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive is wanneer git rebase een -- i argument accepteert. Dit staat voor “Interactive.”Zonder argumenten, de opdracht draait in de standaardmodus. In beide gevallen, laten we aannemen dat we een aparte feature branch hebben gemaakt.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

Git rebase in standaard modus zal automatisch de commits in je huidige werk branch nemen en deze toepassen op de head van de doorgegeven branch.

 git rebase 

Dit rebased automatisch de huidige branch op , wat elke vorm van commit referentie kan zijn (bijvoorbeeld een ID, een branch naam, een tag, of een relatieve verwijzing naar HEAD).

het uitvoeren van git rebase met de -i Start een interactieve rebasessessie., In plaats van alle commits blindelings naar de nieuwe basis te verplaatsen, geeft interactive rebasen je de mogelijkheid om individuele commits in het proces te veranderen. Hiermee kun je de geschiedenis opschonen door een bestaande reeks commits te verwijderen, te splitsen en te wijzigen. Het is als Git commit --amend op steroïden.

 git rebase --interactive 

deze rebased de huidige branch op maar maakt gebruik van een interactieve rebasesessie. Dit opent een editor waar je commando ‘ s kunt invoeren (hieronder beschreven) voor elke commit die gerebased moet worden., Deze commando ‘ s bepalen hoe individuele commits naar de nieuwe basis worden overgedragen. Je kunt ook de commit listing opnieuw rangschikken om de volgorde van de commits zelf te veranderen. Als je eenmaal commando ’s hebt opgegeven voor elke commit in de rebase, zal Git beginnen met het afspelen van commits die de rebase commando’ s toepassen. De rebase-bewerkingscommando ‘ s zijn als volgt:

extra rebase-opdrachten

zoals beschreven op de pagina geschiedenis herschrijven, kan rebase worden gebruikt om oudere en meerdere commits, gecommit bestanden en meerdere berichten te wijzigen., Hoewel dit de meest voorkomende toepassingen zijn, heeft git rebase ook extra commando-opties die nuttig kunnen zijn in meer complexe toepassingen.

• git rebase -- d betekent dat tijdens het afspelen de commit zal worden weggegooid uit het uiteindelijke gecombineerde commit blok.
• git rebase -- p laat de commit zoals deze is. Het zal het bericht of de inhoud van de commit niet wijzigen en zal nog steeds een individuele commit zijn in de branches geschiedenis.
• git rebase -- x tijdens het afspelen voert een commandoregel shell script uit op elke gemarkeerde commit., Een handig voorbeeld zou zijn om de test suite van je codebase op specifieke commits uit te voeren, wat kan helpen regressies te identificeren tijdens een rebase.

Recap

interactief rebasen geeft u volledige controle over hoe uw projectgeschiedenis eruit ziet. Dit biedt ontwikkelaars veel vrijheid, omdat het hen in staat stelt een “rommelige” geschiedenis te committen terwijl ze zich richten op het schrijven van code, en daarna terug te gaan en het op te ruimen.

De meeste ontwikkelaars gebruiken graag een interactieve rebase om een feature branch te polijsten voordat ze het mergen in de hoofdcode base., Dit geeft hen de mogelijkheid om onbelangrijke commits te pletten, verouderde te verwijderen, en ervoor te zorgen dat al het andere in orde is voordat ze committen naar de “officiële” projectgeschiedenis. Voor iedereen zal het eruit zien alsof de hele functie is ontwikkeld in een enkele reeks goed geplande commits.

de echte kracht van interactief rebasen kan worden gezien in de geschiedenis van de resulterende master branch. Voor iedereen, het lijkt erop dat je een briljante ontwikkelaar die de nieuwe functie geïmplementeerd met de perfecte hoeveelheid commits de eerste keer rond., Dit is hoe interactief rebasen de geschiedenis van een project schoon en zinvol kan houden.

configuratieopties

Er zijn enkele rebase-eigenschappen die kunnen worden ingesteld met git config. Deze opties veranderen degit rebase uitvoer look and feel.

• rebase.stat: een boolean die standaard op false is ingesteld. De optie schakelt weergave van visuele diffstat inhoud die toont wat er veranderd sinds de laatste debase.

• rebase.autoSquash: een Booleaanse waarde die het gedrag van --autosquash aan / uitschakelt.,

• rebase.missingCommitsCheck: kan worden ingesteld op meerdere waarden die het rebase-gedrag rond ontbrekende commits veranderen.,/tr>
  

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Wanneer in git rebase --onto mode wordt het commando uitgebreid naar:

    git rebase --onto 

  het --onto commando maakt een krachtiger vorm of rebase mogelijk die het doorgeven van specifieke refs toestaat om de tips van een rebase te zijn.
  laten we zeggen dat we een voorbeeld repo hebben met branches als:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB is gebaseerd op featureA, maar we realiseren ons dat featureB niet afhankelijk is van een van de veranderingen in featureA en gewoon van master kan worden vertakt.

    git rebase --onto master featureA featureB 

  featureA is de., master wordt de en featureB is referentie voor wat HEAD van de zal wijzen. De resultaten zijn dan:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  het begrijpen van de gevaren van rebase

  een waarschuwing om te overwegen bij het werken met Git Rebase is dat merge conflicten frequenter kunnen worden tijdens een rebase workflow. Dit gebeurt als je een langlevende branch hebt die is afgedwaald van master., Uiteindelijk zal je tegen master willen rebasen en op dat moment kan het veel nieuwe commits bevatten waar je branch veranderingen mee in conflict kunnen komen. Dit wordt gemakkelijk verholpen door je branch regelmatig te rebasen tegen master, en vaker commits te maken. De--continue en--abort commandoregelargumenten kunnen worden doorgegeven aangit rebase om de rebase voort te zetten of te resetten bij het omgaan met conflicten.

  een ernstiger rebase-caveat is verloren commits van interactieve geschiedenis herschrijven., Het uitvoeren van rebase in interactieve modus en het uitvoeren van subcommando ‘ s zoals squash of drop zal commits verwijderen uit de directe log van je branche. Op het eerste gezicht kan dit lijken alsof de commits permanent verdwenen zijn. Met git reflog kunnen deze commits hersteld worden en kan de hele rebase ongedaan gemaakt worden. Voor meer informatie over het gebruik van git reflog om verloren commits te vinden, bezoek je onze Git reflog documentatie pagina.

  Git Rebase zelf is niet serieus gevaarlijk., De echte gevarengevallen doen zich voor bij het uitvoeren van geschiedenis herschrijven van interactieve rebases en forceren het pushen van de resultaten naar een remote branch die gedeeld wordt door andere gebruikers. Dit is een patroon dat moet worden vermeden omdat het de mogelijkheid heeft om het werk van andere externe gebruikers te overschrijven wanneer ze pull.

  herstellen van upstream rebase

  als een andere gebruiker heeft gerebased en geforceerd naar de branch waar je commit naar toe, zal een git pull dan alle commits die je hebt gebaseerd op die vorige branch overschrijven met de tip die geforceerd werd gepusht., Gelukkig kun je met git reflog de reflog van de remote branch verkrijgen. Op de reflog van de remote branch kun je een ref vinden voordat deze werd gerebased. U kunt dan uw branch rebasen tegen die remote ref met behulp van de --onto optie zoals hierboven besproken in de geavanceerde Rebase applicatie sectie.

  samenvatting

  In dit artikel hebben wegit rebase gebruik behandeld. We bespraken basic en advanced use cases en meer geavanceerde voorbeelden., Enkele belangrijke discussiepunten zijn:

  • Git rebase standaard vs interactieve modi
  • Git rebase configuratie opties
  • git rebase –op
  • Git rebase verloren commits