Rebasing er i ferd med å bevege seg eller å kombinere en sekvens av forplikter seg til en ny base begå. Rebasing er mest nyttig og lett å visualisere i sammenheng med en funksjon forgrening arbeidsflyt. Den generelle prosessen kan visualiseres som følgende:

Fra et innhold perspektiv, rebasing er å endre base for din gren fra et forplikte seg til en annen slik at det ser ut som om du hadde laget din gren fra et annet forplikte seg., Internt, Git oppnår dette ved å opprette nye forplikter og bruke dem til den angitte base. Det er veldig viktig å forstå at selv om den gren ser det samme, det er sammensatt av helt nye forplikter.

– Bruk

Den primære årsaken til rebasing er å opprettholde en lineær prosjektet historie. For eksempel, tenk deg en situasjon hvor master branch har utviklet seg siden du begynte å jobbe på en funksjon gren., Du ønsker å få de siste oppdateringene til master filial i funksjon gren, men du vil beholde din gren historie rent så det ser ut som om du har jobbet frem den nyeste master gren. Dette gir den senere fordel for en ren fusjonere av funksjonen gren tilbake til master gren. Hvorfor ønsker vi å opprettholde en «ren historie»? Fordelene av å ha en ren historie blir til varige driftsmidler når du utfører Git operasjoner for å utrede innføring av en regresjon. En mer reell situasjon ville være:

1. En feil er identifisert i master gren., En funksjon som jobbet med hell er nå brutt.
2. En utvikler undersøker historien til master gren ved hjelp av git log på grunn av den «rene historie» utbygger er raskt i stand til å resonnere om historien til prosjektet.
3. utbygger kan ikke identifisere når feilen ble introdusert ved hjelp av git log så utvikler utfører en git bisect.
4. Fordi git historien er ren, git bisect har en raffinert sett av forplikter seg til å sammenligne når du leter etter den regresjon., Utvikleren raskt finner forplikte som presenterte rapporten og er i stand til å handle deretter.

finn ut mer om git logg og git bisect på deres individuelle bruk sider.

Du har to alternativer for å integrere funksjonen til master gren: sammenslåing direkte eller rebasing og deretter flette. Det tidligere alternativet resulterer i en 3-veis merge og en flette forplikte seg, mens de sistnevnte resultatene i en spole fremover sammen og en perfekt lineær historie. Følgende diagram viser hvordan rebasing på master gren til rette for en spole fremover sammen.,

Rebasing er en vanlig måte å integrere oppstrøms endringer i din lokale depotet. Å trekke i oppstrøms endringer med Git slå sammen resultatene i en overflødig fusjonere forplikte seg hver gang du ønsker å se hvordan prosjektet har utviklet seg. På den annen side, rebasing er som å si, «jeg vil basere min endringer på hva andre har gjort det allerede.»

ikke rebase offentlig historie

Som vi har diskutert tidligere i å skrive historie, bør du aldri rebase begår når de har blitt presset til en offentlig depotet., Den rebase ville erstatte den gamle begår med nye og det ville se ut som en del av prosjektet ditt historie brått forsvant.

Git Rebase Standard vs Git Rebase Interaktive

Git rebase interaktiv når git rebase aksepterer en -- i argument. Dette står for «Interaktiv.»Uten noen argumenter, kommando kjører i standard-modus. I begge tilfeller, la oss anta at vi har opprettet en egen funksjon 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 standard-modus vil automatisk ta begår i din nåværende arbeid gren og bruke dem til hodet av bestått gren.

 git rebase 

Dette automatisk rebases gjeldende gren på , som kan være noen form for begå referanse (for eksempel en ID, en gren navn, en tag, eller en relativ referanse til HEAD).

å Kjøre git rebase med -i flagget begynner en interaktiv rebasing økt., I stedet for blindt å flytte alle forplikter seg til den nye basen, interaktive rebasing gir deg muligheten til å endre enkelte begår i prosessen. Dette lar deg rense opp historien ved å fjerne, splitting, og å endre en eksisterende serie av forplikter. Det er som Git commit --amend på steroider.

 git rebase --interactive 

Dette rebases gjeldende gren på men bruker en interaktiv rebasing økt. Dette åpner en editor hvor du kan skrive inn kommandoer (beskrevet nedenfor) for hver forplikte seg til å være rebased., Disse kommandoene finne ut hvordan hver enkelt forplikter vil bli overført til den nye base. Du kan også endre rekkefølgen på begå oppføringen for å endre rekkefølgen på de forplikter seg. Når du har angitt kommandoene for hver commit i rebase, Git vil begynne å spille tilbake forplikter å anvende rebase kommandoer. Den rebasing redigere kommandoene er som følger:

Flere rebase kommandoer

Som detaljert i å skrive historie side, rebasing kan brukes til å endre eldre og flere begår, forpliktet filer, og flere meldinger., Mens disse er de mest vanlige programmer, git rebase også har flere opsjoner som kan være nyttig i mer komplekse applikasjoner.

• git rebase -- d betyr under avspilling begå vil bli forkastet fra den endelige kombinert begå blokk.
• git rebase -- p forlater forplikte som er. Det vil ikke endre begå budskapet eller innholdet, og vil fortsatt være en person begår i grenene historie.
• git rebase -- x under avspilling utfører en kommando linje shell-script på hver markerte begå., Et praktisk eksempel kan være å kjøre din codebase ‘ s test suite på bestemte forplikter, som kan bidra til å identifisere regresjoner under en rebase.

Oppsummering

Interaktiv rebasing gir deg full kontroll over hva prosjektet ditt historie ser ut som. Dette gir en mye frihet til utviklere, som gjør det mulig for dem å begå en «rotete» historie mens de er fokusert på å skrive kode, og deretter gå tilbake og rydde opp i ettertid.

de Fleste utviklere liker å bruke en interaktiv rebase å polere en funksjon gren før du flette det inn i main-koden., Dette gir dem muligheten til å ta knekken ubetydelig forplikter, slette utdaterte seg, og sørge for at alt annet er i orden før du forplikter deg til den «offisielle» prosjekt historie. Til alle andre, vil det se ut som hele funksjonen ble utviklet i en enkelt rekke godt planlagt forplikter.

Den reelle makten av interaktive rebasing kan sees i historien av den resulterende master gren. Til alle andre, det ser ut som du er en strålende utvikler som er implementert den nye funksjonen med den perfekte mengden av begår første gang rundt., Dette er hvordan interaktive rebasing kan holde en prosjektets historie ren og meningsfylt.

Konfigurasjon alternativer

Det er noen rebase egenskaper som kan stilles inn ved hjelp av git config. Disse alternativene vil endre git rebase utgang utseende og følelse.

• rebase.stat: En boolsk som er satt til false standard. Alternativet aktiverer eller deaktiverer visning av visuelt diffstat innhold som viser hva som er endret siden siste debase.

• rebase.autoSquash: En boolsk verdi som veksler --autosquash adferd.,

• rebase.missingCommitsCheck: Kan bli satt til av flere verdier som endrer rebase atferd rundt manglende forplikter.,/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 du er i git rebase --onto modus kommandoen utvider til:

    git rebase --onto 

  --onto – kommandoen gir en mer kraftfull form eller rebase som gjør passerer bestemte refs for å være tips av en rebase.
  La oss si at vi har et eksempel repo med grener som:

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

  featureB er basert på featureA, men vi innser featureB er ikke avhengig av noen av endringer i featureA og bare kunne være forgrenet av master.

    git rebase --onto master featureA featureB 

  featureA er ., master blir og featureB er referanse for hva som HEAD av peker til. Resultatene er deretter:

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

  Forstå farene ved rebase

  En påminnelse for å vurdere når du arbeider med Git Rebase er fusjonere konflikter kan bli mer hyppige i løpet av en rebase arbeidsflyt. Dette skjer hvis du har en lang levetid gren som har vendt seg bort fra master., Til slutt vil du ønsker å rebase mot master-og på den tiden kan det inneholde mange nye begår at din gren endringer kan komme i konflikt med. Dette er lett fikse ved å rebasing din gren ofte mot master, og gjør hyppigere forplikter. --continue og --abort kommandolinje-argumenter kan være bestått for å git rebase for å forhånd eller tilbakestille rebase når du arbeider med konflikter.

  En mer alvorlig rebase forbeholdet er tapt begår fra interaktiv historie omskriving., Kjører rebase i interaktiv modus og gjennomføring delkommandoene som squash eller drop vil fjerne begår fra branche er umiddelbar logg. Ved første øyekast kan dette synes som om de begår er permanent borte. Ved hjelp av git reflog disse begår kan bli gjenopprettet og hele rebase kan angres. For mer info om bruk av git reflog for å finne tapte begår, kan du besøke vår Git reflog dokumentasjon side.

  Git Rebase i seg selv er ikke alvorlig farlig., Den virkelige faren tilfeller fremkomme når du utfører historie skrive interaktive rebases og kraft presser resultatene til en ekstern grenen som deles av andre brukere. Dette er et mønster som bør unngås, da det har evnen til å overskrive andre eksterne brukere’ arbeid når de drar.

  Utvinne fra oppstrøms rebase

  Hvis en annen bruker har rebased og kraft presset til gren at du forplikter deg til, en git pull vil da overskrive noen begår du har på basis av at tidligere gren med tips som var makt presset., Heldigvis, ved hjelp av git reflog du kan få den reflog av ekstern grenen. På den eksterne filialens reflog du kan finne en ref før det var rebased. Du kan deretter rebase din gren mot at eksterne ref bruke --onto alternativ som er drøftet ovenfor i Avansert Rebase Program-delen.

  Oppsummering

  I denne artikkelen har vi dekket git rebase bruk. Vi diskuterte grunnleggende og avansert bruk saker og mer avanserte eksempler., Noen viktige diskusjonen poeng er:

  • git rebase standard vs interaktiv modus
  • git rebase konfigurasjon alternativer
  • git rebase –på
  • git rebase mistet begår