Rebasing er processen med at flytte eller kombinere en sekvens af forpligtelser til en ny base commit. Rebasing er mest nyttigt og nemt visualiseres i forbindelse med en funktion forgrening arbejdsgang. Den generelle proces kan visualiseres som følgende:

Fra et indhold, perspektiv, rebasing er ved at ændre bunden af din gren fra en forpligte sig til at en anden gør det ser ud som om du havde oprettet din gren fra et anderledes, til at forpligte sig., Internt opnår Git dette ved at oprette nye forpligtelser og anvende dem på den angivne base. Det er meget vigtigt at forstå, at selvom filialen ser den samme ud, er den sammensat af helt nye forpligtelser.

anvendelse

den primære årsag til rebasing er at opretholde en lineær projekt historie. Overvej for eksempel en situation, hvor hovedgrenen er kommet frem, siden du begyndte at arbejde på en funktionsgren., Du ønsker at få de seneste opdateringer til hovedgrenen i din funktionsgren, men du vil holde din filials historie ren, så det ser ud som om du har arbejdet med den nyeste hovedgren. Dette giver den senere fordel af en ren fusion af din funktionsgren tilbage i mastergrenen. Hvorfor ønsker vi at opretholde en “ren historie”? Fordelene ved at have en ren historie bliver håndgribelige, når man udfører Git-operationer for at undersøge indførelsen af en regression. En mere virkelige verden scenario ville være:

1. en fejl er identificeret i master gren., En funktion, der fungerede med succes, er nu brudt.
2. en udvikler undersøger historien om master gren ved hjælp af git log på grund af den “rene historie” udvikleren er hurtigt i stand til at ræsonnere om historien om projektet.
3. udvikleren kan ikke identificere, hvornår fejlen blev introduceret ved hjælp af git log så udvikleren udfører en git bisect.
4. fordi git-historikken er ren, git bisect har et raffineret sæt forpligtelser, der skal sammenlignes, når man ser efter regressionen., Udvikleren finder hurtigt det commit, der introducerede fejlen og er i stand til at handle i overensstemmelse hermed.

Lær mere om git log og git bisect på deres individuelle brugssider.

Du har to muligheder for at integrere din funktion i hovedgrenen: fusionere direkte eller rebasing og derefter fusionere. Den tidligere mulighed resulterer i en 3-vejs Flet og en flet commit, mens sidstnævnte resulterer i en hurtig fremadfletning og en perfekt lineær historie. Følgende diagram viser, hvordan rebasing på mastergrenen letter en hurtig fremadfletning.,

Rebasing er en almindelig måde at integrere opstrømsændringer i dit lokale lager. Træk i opstrømsændringer med Git merge resulterer i en overflødig merge commit hver gang du vil se, hvordan projektet er kommet frem. På den anden side er rebasing som at sige, “Jeg vil basere mine ændringer på, hvad alle allerede har gjort.”

ikke rebase public history

Som vi tidligere har diskuteret i omskrivningshistorikken, bør du aldrig rebase commits, når de er blevet skubbet til et offentligt lager., Rebasen ville erstatte de gamle forpligtelser med nye, og det ville se ud som om den del af din projekthistorie pludselig forsvandt.

Git Rebase Standard vs Git Rebase Interaktive

Git rebase interactive er, når git rebase accepterer en -- i argument. Dette står for ” interaktiv.”Uden argumenter kører kommandoen i standardtilstand. I begge tilfælde, lad os antage, at vi har oprettet en separat funktionsgren.,

 # 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 standardtilstand vil automatisk tage forpligtelserne i din nuværende arbejdsgren og anvende dem på lederen af den beståede gren.

 git rebase 

Denne automatisk rebases den nuværende gren på , som kan være en slags begå reference (for eksempel et ID, en gren navn, et tag, eller en relativ reference til HEAD).

Kører git rebase med -i flag begynder en interaktiv rebasing session., I stedet for blindt at flytte alle forpligtelser til den nye base, interaktiv rebasing giver dig mulighed for at ændre individuelle forpligtelser i processen. Dette giver dig mulighed for at rydde op i historien ved at fjerne, opdele og ændre en eksisterende række forpligtelser. Det er som Git commit --amend på steroider.

 git rebase --interactive 

Denne rebases den nuværende gren på men bruger et interaktivt rebasing session. Dette åbner en editor, hvor du kan indtaste kommandoer (beskrevet nedenfor) for hver forpligtelse, der skal rebases., Disse kommandoer bestemmer, hvordan individuelle forpligtelser overføres til den nye base. Du kan også omarrangere commit-listen for at ændre rækkefølgen af commits selv. Når du har angivet kommandoer for hvert commit i rebase, begynder Git at afspille commits, der anvender rebase-kommandoerne. Redigeringskommandoerne til gendannelse er som følger:

yderligere rebase-kommandoer

som beskrevet på siden omskrivning af historik kan rebasing bruges til at ændre ældre og flere forpligtelser, engagerede filer og flere meddelelser., Selvom disse er de mest almindelige applikationer, har git rebase også yderligere kommandoindstillinger, der kan være nyttige i mere komplekse applikationer.

• git rebase -- d betyder under afspilning vil commit blive kasseret fra den endelige kombinerede commit-blok.
• git rebase -- p forlader commit som det er. Det vil ikke ændre commitets budskab eller indhold og vil stadig være en individuel commit i filialens historie.
• git rebase -- x under afspilning udfører en kommandolinje shell script på hver markeret commit., Et nyttigt eksempel ville være at køre din kodebase test suite på specifikke commits, som kan hjælpe med at identificere regressioner under en rebase.

Recap

interaktiv rebasing giver dig fuld kontrol over, hvordan din projekthistorik ser ud. Dette giver en masse frihed til udviklere, da det lader dem begå en “rodet” historie, mens de er fokuseret på at skrive kode, så gå tilbage og rydde det op efter det faktum.

de fleste udviklere kan lide at bruge en interaktiv rebase til at polere en funktionsgren, før de fusionerer den til hovedkodebasen., Dette giver dem mulighed for at s .uash ubetydelige forpligtelser, slette forældede og sørge for, at alt andet er i orden, før de forpligter sig til den “officielle” projekthistorie. For alle andre vil det se ud som om hele funktionen blev udviklet i en enkelt serie af velplanlagte forpligtelser.

den reelle effekt af interaktiv rebasing kan ses i historien om den resulterende mastergren. For alle andre ser det ud til, at du er en strålende udvikler, der implementerede den nye funktion med den perfekte mængde forpligtelser første gang., Sådan kan interaktiv rebasing holde et projekts historie ren og meningsfuld.

konfigurationsindstillinger

Der er et par rebase-egenskaber, der kan indstilles ved hjælp afgit config. Disse indstillinger vil ændre git rebase output udseende.

• rebase.stat: en boolesk, der som standard er indstillet til falsk. Indstillingen skifter visning af visuelt diffstat-indhold, der viser, hvad der er ændret siden den sidste debase.

• rebase.autoSquash: en boolsk værdi, der skifter--autosquash adfærd.,

• rebase.missingCommitsCheck: kan indstilles til flere værdier, der ændrer rebase-adfærd omkring manglende forpligtelser.,/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 i git rebase --onto mode kommandoen udvider sig til:

    git rebase --onto 

  --onto kommando giver en mere kraftfuld form eller rebase, der giver passerer specifikke refs at være spidsen af en rebase.
  Lad os sige, vi har et eksempel repo med grene som:

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

  featureB er baseret på featureA, men vi indse, featureB er ikke afhængige af nogen af de ændringer i featureA og bare kunne være forgrenet ud master.

    git rebase --onto master featureA featureB 

  featureA er ., master bliver til og featureB er reference for, hvad HEAD af vil pege på. Resultaterne er så:

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

  forståelse af farerne ved rebase

  en advarsel at overveje, når man arbejder med Git Rebase, er fusionskonflikter kan blive hyppigere under en rebase-arbejdsgang. Dette sker, hvis du har en langlivet gren, der har forvildet sig fra master., Til sidst vil du rebase mod master og på det tidspunkt kan det indeholde mange nye forpligtelser, som dine filialændringer kan være i konflikt med. Dette afhjælpes let ved at rebasing din filial ofte mod master, og gøre hyppigere forpligtelser. --continue og --abort kommandolinje-argumenter, kan blive videregivet til git rebase for at rykke frem eller nulstille den rebase, når der beskæftiger sig med konflikter.

  en mere alvorlig rebase advarsel er tabt forpligter fra interaktiv historie omskrivning., At køre rebase i interaktiv tilstand og udføre underudvalg som s .uash eller drop vil fjerne forpligtelser fra din branches umiddelbare log. Ved første øjekast kan det se ud som om forpligtelserne er permanent væk. Brug af git reflog disse forpligtelser kan gendannes, og hele rebasen kan fortrydes. For mere information om brug af git reflog for at finde tabte commits, besøg vores Git reflog dokumentationsside.

  Git Rebase selv er ikke alvorligt farligt., De reelle faresager opstår, når du udfører historik omskrivning af interaktive rebases og tvinger til at skubbe resultaterne til en fjerngren, der deles af andre brugere. Dette er et mønster, der bør undgås, da det har evnen til at overskrive andre eksterne brugeres arbejde, når de trækker.

  Gendannelse fra upstream-rebase

  Hvis en anden bruger har omgjort og kraft skubbet til den gren, som du forpligte sig til en git pull vil så overskrive alle begår du har baseret ud fra, at tidligere gren med de tip, der var gældende skubbet., Heldigvis kan du ved hjælp af git reflog få reflog af fjerngrenen. På fjerngrenens reflog kan du finde en ref, før den blev rebased. Du kan derefter rebase din filial mod den eksterne ref ved hjælp af indstillingen --onto som beskrevet ovenfor i afsnittet Avanceret Rebase-applikation.

  resum.

  i denne artikel dækkede vigit rebase brug. Vi diskuterede grundlæggende og avancerede brugssager og mere avancerede eksempler., Nogle vigtige diskussionspunkter er:

  • git rebase standard vs interaktive tilstande
  • Git rebase konfigurationsindstillinger
  • git rebase-onto
  • git rebase lost commits