Rebasing är processen att flytta eller kombinera en sekvens av åtaganden till en ny bas commit. Rebasing är mest användbar och lätt visualiseras i samband med en funktion förgrening arbetsflöde. Den allmänna processen kan visualiseras som följande:

ur ett innehållsperspektiv ändrar rebaseringen basen för din gren från en begå till en annan vilket gör att den visas som om du skapat din gren från en annan begå., Internt åstadkommer Git detta genom att skapa nya åtaganden och tillämpa dem på den angivna basen. Det är väldigt viktigt att förstå att även om grenen ser likadan ut, består den av helt nya åtaganden.

användning

den främsta orsaken till rebasering är att upprätthålla en linjär projekthistorik. Tänk till exempel på en situation där huvudgrenen har utvecklats sedan du började arbeta på en funktionsgren., Du vill få de senaste uppdateringarna till huvudgrenen i din funktionsgren, men du vill hålla din filials historia ren så det verkar som om du har arbetat av den senaste huvudgrenen. Detta ger den senare fördelen av en ren sammanslagning av din funktionsgren tillbaka till huvudgrenen. Varför vill vi behålla en ”ren historia”? Fördelarna med att ha en ren historia blir påtagliga när man utför Git-operationer för att undersöka införandet av en regression. Ett mer verkligt scenario skulle vara:

1. en bugg identifieras i huvudgrenen., En funktion som fungerade framgångsrikt är nu bruten.
2. en utvecklare undersöker huvudgrenens historia med git log på grund av ”ren historia” kan utvecklaren snabbt resonera om projektets historia.
3. utvecklaren kan inte identifiera när felet introducerades med git log så utvecklaren utför en git bisect.
4. eftersom git-historiken är ren hargit bisect en raffinerad uppsättning åtaganden att jämföra när man letar efter regressionen., Utvecklaren finner snabbt begå som introducerade felet och kan agera därefter.

Läs mer om git log och git bisect på deras individuella användningssidor.

Du har två alternativ för att integrera din funktion i huvudgrenen: slå samman direkt eller rebasera och sedan slå samman. Det tidigare alternativet resulterar i en 3-vägs sammanfogning och en sammanfogning, medan den senare resulterar i en snabbkoppling och en perfekt linjär historia. Följande diagram visar hur rebasing på huvudgrenen underlättar en snabbmatning framåt.,

Rebasing är ett vanligt sätt att integrera uppströmsändringar i ditt lokala arkiv. Att dra in uppströmsändringar med Git-sammanfogning resulterar i en överflödig sammanfogning varje gång du vill se hur projektet har utvecklats. Å andra sidan är rebasing som att säga, ”Jag vill basera mina förändringar på vad alla redan har gjort.”

rebase inte allmän historia

som vi har diskuterat tidigare i omskrivning historia, bör du aldrig rebase begår när de har drivits till ett offentligt förråd., Rebasen skulle ersätta de gamla begå med nya och det skulle se ut som den delen av din projekthistoria plötsligt försvann.

Git Rebase Standard vs Git Rebase Interactive

git rebase interactive är när git rebase accepterar ett-- i argument. Detta står för ” Interactive.”Utan några argument körs kommandot i standardläge. I båda fallen, låt oss anta att vi har skapat en separat funktion gren.,

 # 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 i standardläge tar automatiskt åtagandena i din nuvarande arbetsgren och tillämpar dem på chefen för den godkända grenen.

 git rebase 

detta återställer automatiskt den aktuella grenen till, vilket kan vara någon form av begå referens (till exempel ett ID, ett grennamn, en tagg eller en relativ referens tillHEAD).

git rebase med flaggan-i börjar en interaktiv rebaseringssession., Istället för att blint flytta alla åtaganden till den nya basen, interaktiv rebasering ger Dig möjlighet att ändra enskilda begår i processen. Detta gör att du kan rensa upp historia genom att ta bort, dela och ändra en befintlig serie åtaganden. Det är somGit commit --amend på steroider.

 git rebase --interactive 

detta rebaserar den aktuella grenen på men använder en interaktiv rebaseringssession. Detta öppnar en redigerare där du kan ange kommandon (beskrivs nedan) för varje åtagande som ska rebaseras., Dessa kommandon bestämmer hur enskilda åtaganden kommer att överföras till den nya basen. Du kan också ordna begå notering för att ändra ordningen på begår sig. När du har angett kommandon för varje begå i rebase, Git kommer att börja spela upp begår tillämpa rebase kommandon. Redigeringskommandona för rebasering är följande:

ytterligare rebaskommandon

som beskrivs på sidan omskrivningshistorik kan rebasering användas för att ändra äldre och flera begår, begått filer och flera meddelanden., Även om dessa är de vanligaste programmen,git rebase har också ytterligare kommandoralternativ som kan vara användbara i mer komplexa applikationer.

• git rebase -- d betyder under uppspelning att commit kommer att kasseras från det slutliga kombinerade commit-blocket.
• git rebase -- p lämnar begå som det är. Det kommer inte att ändra begå budskap eller innehåll och kommer fortfarande att vara en individ begå i grenarnas historia.
• git rebase -- x under uppspelning körs ett kommandoradsskalskript på varje markerad begå., Ett användbart exempel skulle vara att köra kodbasens testsvit på specifika åtaganden, vilket kan hjälpa till att identifiera regressioner under en rebase.

Recap

interaktiv rebasering ger dig fullständig kontroll över hur din projekthistorik ser ut. Detta ger mycket frihet till utvecklare, eftersom det låter dem begå en ”rörig” historia medan de är inriktade på att skriva kod och sedan gå tillbaka och städa upp efter faktum.

de flesta utvecklare gillar att använda ett interaktivt rebase för att polera en funktionsgren innan de slår samman den i huvudkodbasen., Detta ger dem möjlighet att squash obetydliga begår, ta bort föråldrade och se till att allt annat är i ordning innan de förbinder sig till den” officiella ” projekthistoriken. För alla andra kommer det att se ut som att hela funktionen utvecklades i en enda serie välplanerade åtaganden.

den verkliga kraften i interaktiv rebasering kan ses i historien om den resulterande huvudgrenen. För alla andra ser det ut som om du är en lysande utvecklare som implementerade den nya funktionen med den perfekta mängden begår första gången., Så här kan interaktiv rebasering hålla ett projekts historia ren och meningsfull.

konfigurationsalternativ

det finns några rebasegenskaper som kan ställas in medgit config. Dessa alternativ kommer att ändragit rebase utdata utseende och känsla.

• rebase.stat: en boolesk som är inställd på false som standard. Alternativet växlar visning av visuellt diffstat-innehåll som visar vad som ändrats sedan det senaste debase.

• rebase.autoSquash: ett booleskt värde som växlar beteendet--autosquash.,

• rebase.missingCommitsCheck: kan ställas in på flera värden som ändrar rebase beteende runt saknade begår.,/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., När kommandot i git rebase --onto expanderar till:

    git rebase --onto 

  kommandot --onto möjliggör en mer kraftfull form eller rebase som gör det möjligt att skicka specifika refs som tips för en rebase.
  låt oss säga att vi har ett exempel repo med grenar som:

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

  featureB är baserat på featureA, men vi inser featureB är inte beroende av någon av förändringarna i featureA och kan bara förgrenas bort mästare.

    git rebase --onto master featureA featureB 

  featureA är., masterbliroch featureB är referens för vadHEADI pekar på. Resultaten är då:

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

  förstå farorna med rebase

  en varning att tänka på när du arbetar med Git Rebase är sammanfoga konflikter kan bli vanligare under en rebase arbetsflöde. Detta inträffar om du har en långlivad gren som har avvikit från mästaren., Så småningom kommer du vill rebase mot master och vid den tiden kan det innehålla många nya åtar sig att din gren förändringar kan strida mot. Detta är lätt åtgärdas genom att rebasera din gren ofta mot master, och göra mer frekventa begår. Kommandoradsargumenten--continue och--abort kan skickas tillgit rebase för att avancera eller återställa rebasen när det handlar om konflikter.

  en mer allvarlig rebase caveat förloras begår från interaktiv historia omskrivning., Att köra rebase i interaktivt läge och utföra underkommandon som squash eller drop kommer att ta bort begår från din branches omedelbara logg. Vid första anblicken kan detta visas som om åtagandena är permanent borta. Använda git reflog dessa åtaganden kan återställas och hela rebasen kan ångras. För mer information om hur du använder git reflog för att hitta förlorade åtaganden, besök vår git reflog-dokumentationssida.

  Git Rebase i sig är inte allvarligt farligt., De verkliga farofallen uppstår när historiken skrivs om interaktiva rebaser och tvingar resultaten till en avlägsen gren som delas av andra användare. Detta är ett mönster som bör undvikas eftersom det har förmågan att skriva över andra fjärranvändares arbete när de drar.

  återhämta sig från uppströms rebase

  om en annan användare har rebaserat och tvinga drivit till den gren som du förbinder dig till, kommer engit pull att skriva över alla åtaganden du har baserat på den tidigare grenen med spetsen som drevs., Lyckligtvis använder dugit reflog du kan få reflog av fjärrgrenen. På den avlägsna grenens reflog kan du hitta en ref innan den rebaserades. Du kan sedan göra om din filial mot den fjärrref med alternativet--onto enligt ovan i avsnittet Avancerat Rebase-program.

  sammanfattning

  i den här artikeln omfattade vigit rebase användning. Vi diskuterade grundläggande och avancerade användningsfall och mer avancerade exempel., Några viktiga diskussionspunkter är:

  • git rebase standard vs interactive modes
  • git rebase configuration options
  • git rebase –onto
  • git rebase lost commits