Sådan bruger du Git Rebase trin for trin uden at rode det til

Hvis du har arbejdet med Git i Visual Studio i et stykke tid , har du sikkert hørt ting som "lav en rebase før du åbner pull request" eller "udfør ikke rebase på en fjernbetjening", og måske er du stadig lidt forvirret og ikke helt sikker på, hvad der foregår i historien. Git rebase har et ry for at være kraftfuld, men også for at være farlig, og den respekt stammer ofte fra ikke fuldt ud at forstå, hvad den gør under motorhjelmen.

I denne guide vil vi roligt gennemgå, hvad rebase er, hvordan det adskiller sig fra merge, hvornår du bør bruge rebase, og hvornår det er bedst at undgå det , hvordan interaktiv rebase fungerer, farerne ved at overskrive historikken, og hvordan man gendanner, hvis noget går galt. Alt forklares på standardspansk (fra Spanien) med praktiske eksempler og ingen antagelser.

Hvad er Git-rebase?

Git rebase er en kommando, der giver dig mulighed for at "flytte" en række commits til en ny base i Git-historikgrafen. I stedet for at flette to branches sammen ved at oprette en merge commit, "genanvender" rebase commits fra én branch én efter én til et andet punkt i historikken, hvilket genererer nye commit-ID'er og efterlader en renere og mere lineær tidslinje.

Forestil dig, at du har en master- branch , og startende med commit A opretter du en feature- branch . I denne branch foretager du adskillige commits, mens ændringerne fortsætter i master. Rebasing giver dig mulighed for at fortælle Git: "tag mine feature-commits og omskriv dem, som om jeg havde lavet dem direkte oven på de seneste ændringer i master ", hvilket resulterer i en mere organiseret historik uden mellemliggende merge-commits.

Denne operation betyder, at Git omskriver historikken for den branch, du rebaserer . Det er ikke bare en visuel reorganisering: nye commits oprettes med nye hashes, og de gamle refereres ikke længere (selvom de kan forblive i refloggen et stykke tid). Derfor siges rebasing at være både kraftfuldt og delikat.

En måde at forstå det på er at tænke på det som følger: Mens merging forbinder to arbejdslinjer med et enkelt konvergenspunkt, "løfter" rebasing din branch, kopierer dens commits og indsætter dem på en anden branch, som om de altid var opstået der. Resultatet er normalt en renere historik, men prisen er at ændre den faktiske rækkefølge af, hvordan ændringerne blev foretaget.

Rebase versus merge: samme mål, forskellige veje

Den primære kontekst for brug af rebase er, når du vil integrere ændringer fra en branch til en anden . Git tilbyder to muligheder: merge og rebase. Begge flytter i sidste ende koden til det samme sted, men det spor, de efterlader i historikken, er meget forskelligt.

Med `git merge` inkorporerer din nuværende branch commits fra en anden branch, og en ekstra merge-commit genereres (undtagen i tilfælde af spolning fremad). Dette bevarer den oprindelige commit-historik intakt, men hvis der er mange merges, kan commit-grafen ende med at ligne en tallerken spaghetti. Fordelen er, at du ikke overskriver noget ; du tilføjer blot.

Med `git rebase` , i stedet for at oprette en merge commit, tager du dine commits og placerer dem oven på en anden branch, som om de altid havde været der. Resultatet er en lineær historik, hvor det er tydeligt, "hvad" hver ændring er bygget på. Ulempen er, at commit-hasherne er ændret , og hvis disse commits allerede er delt, kan du alvorligt komplicere det eksterne repository og dine kollegers.

I store teams er det almindeligt at kombinere begge strategier: rebase bruges på lokale grene eller før sammenlægning for at rydde op i en funktions historik, og derefter integreres den i hovedgrenen med en sammenlægning (nogle gange uden spol frem) for at opretholde et klart integrationspunkt.

Nøglen er at forstå, at hverken merging eller rebasing i sagens natur er "bedre"; de er forskellige værktøjer. Merging er sikrere og mere transparent; rebasing er mere elegant med hensyn til historik, men involverer ansvar, når man omskriver commits.

Grundlæggende brug af Git rebase

Det mest typiske use case for rebase er, når du arbejder på en feature branch og ønsker at hente de seneste ændringer fra hovedbranchen (f.eks. master eller develop) uden at oprette en yderligere merge commit. Den klassiske arbejdsgang ville se nogenlunde sådan ud:

Du er inden for dit arbejdsområde, for eksempel feature/login, og grenen Mesteren har avanceret med nye commits siden du åbnede funktionen. For at indhente det forsømte lineært skal du gøre følgende:

git checkout feature/login
git fetch origin
git rebase origin/master

Med denne kommando tager Git dine commits fra feature/login og genanvender dem til den seneste commit i origin/master . Hvis der ikke er nogen konflikter, ender du med en historik, hvor det ser ud til, at dine ændringer altid blev foretaget til den mest opdaterede version af master.

Du kan også rebase fra målgrenen, for eksempel:

git checkout feature/login
git rebase master

Dette forudsætter, at din lokale mastermappe er opdateret. Resultatet er det samme: dine feature-commits overskrives over master . I begge tilfælde afspilles hver commit igen, og hvis der er konflikter, vil de blive præsenteret for dig én efter én, så du kan løse dem.

En anden meget almindelig fremgangsmåde er at overskrive en gren, der oprindeligt var baseret på en anden mellemliggende gren. For eksempel har du en feature- gren , der igen fungerer som basis for en branch . Hvis du derefter beslutter, at grenen skal linkes direkte til master i stedet for feature, kan du trykke på:

git checkout branch
git rebase master

Effekten er, at grenen "hopper" fra den gamle base (feature) til den nye base (master) , idet den beholder sine ændringer, men er afhængig af et andet punkt i commit-grafen.

Omarranger ikke den offentlige optegnelse

Den primære sikkerhedsadvarsel vedrørende rebasing er meget klar: omskriv ikke commits, der allerede er blevet delt eksternt, og som andre personer muligvis baserer deres arbejde på. Dette er især vigtigt i brancher som master, develop eller andre kollaborative brancher.

Når du skyder over en gren, og så git push -f o git push --force-with-leaseDet du siger er: "min version af historikken tilsidesætter den på serveren." Hvis nogen har foretaget commits til den eksterne branch, efter du har klonet eller droppet den, Disse commits kan gå tabt eller generere komplicerede divergenser. at reparere.

Forestil dig dette scenarie: to personer kloner et repository, der hver især arbejder på deres lokale branch baseret på den samme eksterne branch, og den ene af dem beslutter sig for at rebase og fremtvinge en push. Den anden person fortsætter med at arbejde med den gamle version. Så snart de henter eller forsøger at pushe deres ændringer, vil Git registrere, at deres base ikke matcher den eksterne , og hovedpinen vil begynde.

Derfor anbefales det generelt at bruge rebase på lokale branches eller feature branches, der endnu ikke er blevet commit . Hvis du har brug for at rydde op i commits, før du pusher dem for første gang, er det perfekt. Hvis branchen allerede er på den eksterne server, og andre arbejder på den, er det bedst at tænke sig grundigt om, koordinere med teamet, og hvis du beslutter dig for at omskrive, tydeligt annoncere det.

Den gyldne regel, der ofte gentages, er: lad være med at rebase commits, der ikke udelukkende er dine . Hvis du er den eneste person, der har rørt disse commits, og du ved, hvad du laver, så bare gør det; ellers er det bedre at merge dem eller åbne en anden branch for at reorganisere.

Standard Git-rebase vs. interaktiv Git-rebase

Når vi taler om rebasing, taler vi faktisk om to typer: "normal" (ikke-interaktiv) rebasing og interaktiv rebasing . Den første flytter blot dine commits fra én base til en anden; den anden giver dig mulighed for at redigere, omarrangere, flette eller slette commits under processen.

Du bruger standardrebasen, for eksempel med git rebase master o git rebase origin/developHer anvender Git mekanisk hver commit fra din branch til den nye base og stopper kun, hvis der er konflikter, hvorefter du griber ind for at løse dem og fortsætter. git rebase --continue.

Interaktiv rebasing aktiveres ved hjælp af -i- indstillingen , der typisk angiver et interval af commits fra branch-spidsen og bagud. For eksempel:

git rebase -i HEAD~5

Dette fortæller Git, at du vil "lege" med de sidste fem commits. Din teksteditor, der er konfigureret til Git (normalt vim eller nano som standard), åbner med en liste over disse commits, hver efterfulgt af ordet ` pick` . Det er her, du kan erstatte `pick` med andre instruktioner for at omskrive historikken, som du ønsker.

Denne interaktive tilgang er designet til at finpudse en række commits, før de deles: flette mindre ændringer, rette beskeder, opdele for store commits eller direkte fjerne commits, der ikke burde nå det eksterne arkiv.

Yderligere omorganiseringskommandoer i interaktiv rebase

I den fil, der åbnes git rebase -i Du vil se noget i retning af dette:

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B

Ideen er, at du kan erstatte `pick` med andre kommandoer for at ændre, hvordan hver commit håndteres under rebasen. De mest almindelige er:

• plukke (p)Brug commit'en som den er.
• omformulering (r)Anvend commit'en, men stop for at ændre beskeden.
• rediger (e)Anvend commit og stop, så du kan ændre indholdet (f.eks. tilføje eller fjerne filer) ved hjælp af git commit --amend.
• squash (s): fletter denne commit med den forrige og tillader redigering af den kombinerede besked.
• reparation (f): samme som squash, men kasserer beskeden fra denne commit og beholder den fra den forrige.
• dråbe (d)fjerner denne commit fra historikken.

I eksemplet ovenfor kan du for eksempel flette en commit, der retter en tidligere , flytte en op, opdele en stor og rette en stavefejl. Den redigerede fil kan se sådan ud:

pick 1fc6c95 Patch A
squash fa39187 something to add to patch A
pick 7b36971 something to move before patch B
pick 6b2481b Patch B
fixup c619268 A fix for Patch B
edit dd1475d something I want to split
reword 4ca2acc i cant' typ goods

Når du gemmer og lukker editoren, vil Git begynde at udføre disse kommandoer i rækkefølge og stoppe, når det kræver din indgriben (for eksempel for at bekræft meddelelsen som følge af en squash(så du kan foretage ændringer med redigering eller omskrive beskeden i omformulering). Hvert stop viser dig i terminal hvad du skal gøre, og minder dig om, at når du er færdig, skal du løbe git rebase --continue.

På et tidspunkt vil Git åbne en fil med indhold, der ligner:

# This is a combination of two commits.
# The first commit's message is:
Patch A
# This is the 2nd commit message:
something to add to patch A

Du kan lade den kombinerede besked være, som den er, eller redigere den for bedre at repræsentere den kombinerede ændring . Gem igen, luk editoren, og rebasen fortsætter, indtil alle kommandoer er blevet behandlet.

Oversigt over interaktiv rebase-flow

Den komplette proces med en interaktiv rebase følger typisk dette mønster: først vælger du commit-området (f.eks. HEAD~7 ), Git åbner filen, der indeholder listen over commits, og du redigerer kommandoerne og linjerækkefølgen, så de matcher den historik, du ønsker at opnå. Efter gemning itererer Git gennem hver instruktion og stopper, hvor det er nødvendigt, og når du når slutningen uden fejl , har din branch en fuldstændig omformet historik.

Hver gang den stopper, uanset om det er for en redigere eller på grund af en sammenflettet konflikt, kan du ændre filer, bruge git add, lav en git commit --amend Hvis det er relevant, og når du er tilfreds med tilstanden, kan du returnere den til git rebase --continueHvis du begår en alvorlig fejl eller indser, at du har bragt dig selv i en knibe, kan du altid afbryde med git rebase --abort at vende tilbage til den tilstand, der var gældende før overhalingsmanøvren blev påbegyndt.

Det typiske resultat af intelligent brug af interaktiv rebasing er en mere logisk og læsbar serie af commits: mindre støj, færre "rettelse af typografiske fejl", færre gentagne commits og tydeligere beskeder. Dette gør det meget nemmere at gennemgå historikken, forstå, hvad der blev ændret og hvorfor, og udføre fremtidig halvering eller fejlfinding.

Nyttige konfigurationsmuligheder for rebase

Git har adskillige konfigurationsmuligheder, der påvirker rebase-adfærden og kan gøre dit liv lettere, hvis du bruger det regelmæssigt. En af de mest kendte er den, der tillader `git pull` at bruge rebase i stedet for merge som standard:

git config --global pull.rebase true

Med dette, hver gang du gør det git pullGit vil forsøge at overskrive dine lokale ændringer med nye commits fra fjernbetjeningen i stedet for at oprette en merge-commit. Det er en bekvem måde at vedligeholde en lineær lokalhistorie uden at skulle huske altid at skrive git pull --rebase.

Du kan også justere editoren til interaktiv tilstand, konfigurere aliasser til lange rebase-kommandoer eller aktivere muligheder som autostash i bestemte streams, selvom det er tilrådeligt at bruge dem forsigtigt for ikke at miste overblikket over, hvad Git gør med dine ikke-committede ændringer.

Avanceret reorganiseringsansøgning

Når du har mestret grundlæggende, interaktiv rebasing, kan du begynde at bruge det i mere avancerede scenarier, f.eks. når du har flere afhængige grene og ønsker at rebasere dem uden at overbelaste mastergrenen. For eksempel kan du have en klientgren og en servergren , der er afhængige af hinanden, og efter nogle ændringer ønsker du, at begge skal være baseret på en mastergren, der allerede inkorporerer visse refaktoreringer.

I en sådan situation kan du først overskrive klient på master, spole frem til master og derefter overskrive server på den nye master . Denne type manøvre sikrer, at historikken tydeligt viser, hvilke ændringer der tilhører hver branch, og i hvilken logisk rækkefølge de blev anvendt, uden en kæde af krydsfletninger.

Det er også muligt at "reorganisere en reorganisering": hvis nogen har overskrevet en gren, og du senere har brug for at overskrive den omskrevne historik med dit eget arbejde, tillader Git dig at gøre det, selvom dette øger sandsynligheden for konflikter og forvirring . I samarbejdsmiljøer er det tilrådeligt at planlægge disse operationer meget omhyggeligt og om nødvendigt bruge historikdiagrammer for at undgå at fare vild.

Forståelse af farerne ved reorganisering

Den største fare ved rebasing ligger i selve dens fordel: det omskriver historien . Det er fantastisk til at få tingene til at se godt ud, men det er et tveægget sværd, hvis commits allerede er blevet udgivet, eller hvis flere personer er afhængige af dem i deres daglige arbejde.

Forestil dig, at du kloner et repository og begynder at arbejde på din lokale branch, mens andre kolleger fortsætter med at pushe ændringer til hovedbranchen. Hvis en af ​​dem beslutter sig for at rebase den hovedbranch og gennemtvinger et push, kan de commits, du brugte som base, forsvinde fra det eksterne repository, eller deres hashes kan blive ændret. Fra dit lokale perspektiv fortæller din historie én historie; fra det eksterne repository fortæller den en anden.

Når du forsøger at udføre en pull eller et push, vil Git blive tvunget til at afstemme to inkompatible historikker og kan ende med at oprette mærkelige merges eller afvise pushet. Du vil ofte ende med duplikerede commits med det samme indhold, men forskellige hashes, og en endnu mere indviklet historik end den, du startede med.

En anden risiko er, at mister information på grund af et hensynsløst tvangsskubHvis en anden har foretaget legitime commits på fjernbetjeningen, mens du omskriver historikken, git push --force Du kan blot overskrive disse ændringer og få dem til at forsvinde. Det kan kræve meget tid og viden om reflogs at gendanne dem, medmindre der er gået for lang tid.

Af alle disse grunde betragtes rebalancering som et "fantastisk" værktøj, men et værktøj, der skal bruges med omtanke. På et individuelt plan giver det dig mulighed for at opretholde en pletfri historik; på et teamplan kan det, hvis det misbruges, forstyrre teamworket og skabe vanskeligt løselige konflikter.

Genopretning efter en reorganisering på højere niveau

Hvis en rebase kommer ud af kontrol, er det første, man skal gøre, ikke at gå i panik. Git fører en log kaldet en reflog , der gemmer de tidligere positioner af referencer (som HEAD) i et stykke tid. Det betyder, at selvom du har overskrevet commits, kan du muligvis stadig få adgang til dem og gendanne den tidligere tilstand.

Midt i en overhalingsmanøvre, der går galt, er det hurtigste at gøre normalt:

git rebase --abort

Med dette vil Git forsøge at bringe dig tilbage til det præcise punkt, hvorfra du startede rebase-operationen, som om du aldrig var begyndt. Dette er ideelt, når du for eksempel befinder dig i en endeløs kæde af konflikter og beslutter, at det ikke er værd at fortsætte ad den vej.

Hvis problemet er, at du allerede har gennemført rebasen og endda udført et tvungent push, bliver tingene mere komplicerede. Lokalt kan du bruge git-reflog at finde hashen for den commit, du var ved før rebasen, og når du har den, lave en git reset --hard til det punkt. Men hvis du har overskrevet fjernbetjeningen, og andre kloner allerede er blevet opdateret, At gå tilbage kræver koordinering fra hele holdet og i nogle tilfælde acceptere, at en del af værket er gået "tabt" i den forstand, at det ikke længere er en del af den officielle historie.

Når en rebase-fejl påvirker flere personer, involverer den praktiske løsning normalt at blive enige om et nyt startpunkt i en branch (for eksempel at oprette en ny branch fra en sund commit) og hente ændringer fra de berørte branches , enten ved at udvælge ændringerne eller ved at anvende programrettelser. Det er besværligt, men det er generelt at foretrække frem for at forsøge at "magisk fortryde" en delt historik, der allerede er blevet ændret flere gange.

Flet konflikter i rebase

Merge-konflikter under en rebase fungerer på samme måde som dem i en normal merge, bortset fra at de optræder commit for commit . Hver gang Git forsøger at anvende en commit og registrerer, at det samme fragment af en fil er ændret på en inkompatibel måde i basen, markeres konflikten i filerne.

I filen vil du se afgrænsningstegn såsom:

<<<<<<< HEAD
contenido de tu rama actual
=======
contenido de la rama rebasada
>>>>>>> updated_address

Mellem <<<<<<< HEAD og ======== har du indholdet af den ene version, og mellem ======== og >>>>>>> den anden. Din opgave er at redigere filen, kun beholde den kombination, der giver mening for projektet, og fjerne disse bogmærkelinjer.

Når indholdet i alle berørte filer er blevet løst, bruger du git add <archivo> for at markere konflikter som løst. Derefter kører du git rebase --continue så Git kan fortsætte til den næste commit i serien. Hvis du støder på en konflikt, der ikke er værd at løse for den specifikke commit, har du også muligheder som f.eks. git rebase --skip at springe det over, selvom det indebærer udelad helt den commit af den resulterende historie.

Fordi rebasing anvender commits efter hinanden i brancher med mange ændringer og store forskelle fra basen, kan det være besværligt: ​​hver commit, der berører det samme modstridende stykke kode, vil tvinge dig til at rette det. I sådanne tilfælde kan en normal merge eller omarrangering af ændringerne først for at reducere konfliktoverfladen være mere effektivt.

Git rebase, push-force og push-force-with-lease

Når du omskriver historikken for en gren, og den gren er forbundet til en fjernbetjening, vil du støde på Gits sikkerhedstjek: hvis fjernbetjeningen har en anden historik, en simpel git push Den vil blive afvist. For at erstatte den historie, skal du have et pres.

Der er to almindelige variationer: git push --force y git push --force-with-leaseDen første overskriver uden at stille spørgsmål, mens den anden tilføjer en slags "sikkerhedsnet" for at forhindre tilsidesættelse af andre personers commits. Med --force-with-leaseGit tjekker, at fjernbetjeningen stadig peger på den commit, du oprettede; hvis nogen har ændret branchen på serveren, mens du omskrev din lokale historik, vil push'et blive afvist.

Forestil dig et scenarie, hvor du har en række commits på den eksterne branch og beslutter, at en af ​​dem (for eksempel c2) er forkert. Lokalt omskriver du den, genererer nye commits (c3, c4) og ønsker, at disse skal blive den nye virkelighed. Hvis ingen andre har rørt branchen, vil et push med `--force-with-lease` opdatere den eksterne branch uden problemer. Men hvis nogen har tilføjet f.eks. commit c5, mens du forberedte dine ændringer, vil dette flag forhindre dig i at overskrive deres arbejde ved et uheld.

Kort sagt, hvis du allerede har antaget, at du skal fremtvinge et push efter en rebase, er den sædvanlige fremgangsmåde at bruge git push --force-with-lease medmindre du har en helt specifik grund til at ville det overskriv absolut alt med --forceAlligevel er det tilrådeligt at kommunikere det til teamet og koordinere timingen for at minimere konflikter.

Rebase, branch-kontekster og workflow

En anden interessant måde at forstå rebase på er at tænke på branches som arbejdskontekster , der deler en del af historikken, men derefter udvikler sig ad separate stier. Hvis du for eksempel følger en git-flow-arbejdsgang, kan du have en develop-branch, hvorfra funktionelle branches oprettes (A1, A2 osv.).

Når du er i A1-konteksten, påvirker alt, hvad du gør der, ikke udviklingen, før du udfører en merge eller rebase. Det er som at have to parallelle tidslinjer , der deler en fælles oprindelse, men akkumulerer forskellige ændringer. Med en merge forbinder du disse tidslinjer, og Git registrerer en commit, hvor de konvergerer; med en rebase reorganiserer du A1-tidslinjen, så den ser ud til altid at have været et par skridt foran udviklingen.

Hvis Pepe arbejder på develop og Nacho arbejder på A1 under udvikling, vil der komme et tidspunkt, hvor develop har nye commits, og A1 også vil have nye commits. Hvis Nacho vil undgå en merge-commit, når han integrerer A1 i develop, kan han gøre følgende:

git checkout A1
git rebase develop

Git vil bringe commits fra develop "under" dem fra A1 og omskrive A1's historik, så dens ændringer vises oven på den seneste version af develop. Når man ser på historikken, ser det ud til, at Nacho altid har brugt den mest opdaterede version af develop, selvom det faktisk ikke var tilfældet i realtid.

Denne type arbejdsgang er meget praktisk, når du arbejder alene, eller når A1-grenen ikke er blevet delt endnu. Problemet opstår, når A1 allerede er på den eksterne server, og andre teammedlemmer har pushet den. Hvis Nacho rebaserer A1 på develop-grenen og derefter tvinger et push, bryder han forbindelsen mellem den eksterne version og den lokale version , som alle andre har, hvilket tvinger dem til at synkronisere med en historie, der ikke længere ligner den, de havde.

Rebounds og resulterende konflikter i teamwork

I et samarbejdsscenarie, som det vi lige har beskrevet, kan interaktionen mellem rebasing og hver persons lokale repositories være delikat. Når Nacho rebaserer A1, løser han konflikter lokalt og, tilfreds med resultatet, udfører en git push --force-with-leaseFjernbetjeningen afspejler nu den nye, omskrevne historie.

I mellemtiden bruger Pepe stadig sin lokale kopi af A1, som stadig er i pre-rebase-versionen. Hvis Pepe henter eller forsøger at pushe ændringer, vil Git registrere, at hans historik afviger fra den eksterne . I bedste fald bliver han nødt til at nulstille sin lokale branch til den nye eksterne HEAD og genanvende sine ændringer; i værste fald kan han miste arbejde, hvis han ikke er forsigtig og udfører en hard reset uden at gemme noget.

Derfor er det vigtigt, når man ombaserer en delt branch, tydeligt at underrette resten af ​​teamet om eksplicit at opdatere deres lokale branch , for eksempel ved at bruge:

git fetch origin
git checkout A1
git reset --hard origin/A1

Disse typer operationer bør være undtagelser, ikke reglen. Til daglig brug er det normalt bedst at begrænse rebasing til personlige funktionsgrene og lade delte grene (udvikle, mastere) have en merge-baseret historik, som ikke ødelægger nogens lokale kloner.

Med hensyn til konflikter, der opstår under en rebase, er processen altid den samme: Git præsenterer hver konflikt commit for commit, du redigerer de involverede filer og markerer ændringerne som løst med git add og du fortsætter med git rebase --continueHvis situationen af ​​en eller anden grund kommer ud af kontrol, kan du afbryde og gentænke strategien.

Interaktiv rebase: sjov og oprydning for alle

Selvom den kun kort nævnes i mange tutorials, er den interaktive rabattilstand et af de bedste værktøjer til at skabe en historik. ren, ensartet og nem at gennemgå. Med git rebase -i I en enkelt session kan du flette små commits, rette beskeder og flytte commits op eller ned. El tiempo, opdele en stor commit i flere mere logiske, eller blot slette ændringer, der ikke giver mening.

Hvis du for eksempel vil forfine de sidste syv commits, skal du køre:

git rebase --interactive HEAD~7

Din editor åbner med en liste over disse syv commits. Derfra kan du beslutte, om en bestemt commit med mindre rettelser skal flettes sammen med den oprindelige commit af funktionaliteten (ved hjælp af squash eller fixup ), om en anden commit skal flyttes før "Patch B", om en tredje commit skal opdeles i to med edit , eller om en besked med stavefejl skal rettes med reword.

Det fantastiske er, at alt dette arbejde bliver gjort. før ændringerne deles med resten af ​​verden, så det, der når ud til det eksterne team, er allerede en rimelig ren registrering. Dette ser ikke kun bedre ud: det gør det nemmere for en anden udvikler at gennemgå dine commits, med et hurtigt overblik forstå, hvad hver enkelt bidrager med, og om nødvendigt bruge værktøjer som git bisect for at finde det præcise punkt, hvor en fejl blev introduceret.

Det er dog værd at huske den gamle regel: alt hvad du gør med interaktiv rebasing omskriver commit-hashes. Brug det sparsomt på branches, der kun findes på din maskine , og med ekstrem forsigtighed på enhver branch, der allerede er blevet migreret til en fjernserver.

Kort sagt er rebase (og især dens interaktive tilstand) en slags "historikeditor" til Git. Brugt korrekt giver det dig mulighed for at vedligeholde et repository med en meget læsbar og professionel historik; brugt forkert kan det forårsage forvirring og hovedpine, især når det blander allerede delte branches og gennemtvinger pushes uden koordinering.

Det tager tid at mestre denne kommando, men når du forstår præcis, hvad den gør ved dine commits, bliver den et vigtigt værktøj til at arbejde med branches, holde historikken ren og samarbejde problemfrit på projekter af enhver størrelse.