En stor grunn til at utviklere bruker et kildekontrollsystem som Git, er for å unngå katastrofer. Hvis du gjør noe så enkelt som å feilaktig slette en fil, eller hvis du oppdager at alle endringene du har gjort i et dusin filer, kan du angre det du har gjort med lite bry.
Noen Git-feil er mer skremmende og vanskelig å reversere, selv for erfarne Git-brukere. Men med litt forsiktighet - og forutsatt at du ikke får panikk - kan du rulle tilbake fra noen av de verste Git-katastrofene som er kjent for programmerere.
Her er en liste over flere av de større Git boo-boos, sammen med tips for å støtte ut av dem og hindre noen av dem. Jo lenger du går ned på listen, jo større blir katastrofene.
Git feil nr. 1: Du har glemt å legge til endringer i den siste forpliktelsen
Dette er en av de enkleste Git-feilene å komme seg fra. La oss si at du har arbeidet litt med en lokal filial, og så innsett at du ikke iscenesatte en rekke nødvendige filer. Eller du glemte å legge til bestemte detaljer i kommisjonen.
Ingen frykt. Først, hvis du har nye endringer som skal arrangeres, gjør du det. Skriv deretter inn git commit --endre for å redigere forpliktelsesmeldingen. Når du er ferdig, trykker du på Esc og skriver inn : xq for å lagre og gå ut av redaktøren. (Dette siste trinnet er det som ofte forvirrer Git-nykommere, som ikke alltid innser at den innebygde Git-redigereren er veldig sitt eget dyr.)
Hvis du bare endrer filer, og du ikke trenger å endre forpliktelsesmeldingen, kan du bruke git commit --amend --no-edit for å legge til filene og hoppe over redigeringsprosessen for meldinger.
En måte å unngå denne typen feil er å justere måten du gjør på i Git. Hvis du jobber med noe der du kontinuerlig forplikter deg til å spore trinnvise revisjoner, kan du gjøre det i en kaste gren. Mens du gjør dette, må du dokumentere de store endringene du gjør et sted - ikke vent til du står overfor git begå kommandolinje for å skrive alt ned. Så når du når en stor milepæl, bruk git merge - squash fra den bortkastede filialen din for å lagre resultatene til den pågående grenen som en enkelt, ren forpliktelse, og bruk notatene du har tatt for forpliktelsesmeldingen.
Git feil nr. 2: Du begikk endringer til (lokal) mester
En annen vanlig sak: Du har pliktoppfyllende begått en rekke endringer ... men til mastergrenen til repoen din ved en feiltakelse. Hva du egentlig ønsket å gjøre var å forplikte dem til en ny gren, eller til det dev gren du har spesielt for å bryte endringer.
Alt er ikke tapt. Denne feilen kan løses i tre kommandoer:
git gren ny-grengit reset HEAD ~ --hard
git checkout new-branch
Den første kommandoen oppretter den nye grenen vi vil jobbe med. Den andre kommandoen tilbakestiller hovedgrenen til like før siste forpliktelse, men lar endringene du nettopp har gjort i ny gren. Til slutt bytter vi til den nye grenen der endringene dine venter på deg.
Hvis du har gjort flere forpliktelser, bruk git reset HEAD ~ --hard, hvor er antall forpliktelser tilbake du vil gå. Eller du kan bruke git reset , hvor er hash-ID-en til målforpliktelsen hvis du har det praktisk.
For å unngå denne feilen, må du vane deg med å lage nye filialer og bytte til dem, selv om de bare skal kastes når du begynner noen økt med koden din.
Git feil nr. 3: Du søpplet en fil eller katalog
En annen vanlig katastrofe er å feilsøke innholdet i en fil ... og bare finne ut om det mange forplikter seg til filialen etter faktum. Heldigvis er det en enkel løsning.
Bruk først git logg eller IDEs innebygde Git-verktøy for å finne hash-ID for en forpliktelse fra før filen ble endret. Bruk deretter git checkout hash_id - / path / to / file å sjekke ut kun filen fra den aktuelle forpliktelsen. Merk at banen skal være relativt til roten til prosjektet. Dette plasserer den tidligere versjonen av filen i prosjektets iscenesettelsesområde.
Hvis du bare vil gå tilbake n forplikter deg, du trenger ikke hash-ID-en. Du kan bare utstede kommandoen git checkout HEAD ~ - / path / to / file, hvor er antall forpliktelser du vil gå tilbake.
Hvis du vil sjekke ut en hel katalog av filer, og bruk deretter Gits jokertegnformat for filstier. For eksempel inngit checkout HEAD ~ 1 - ./src/** vil ta deg tilbake en forpliktelse og gjenopprette alt i / src katalog fra roten til prosjektet.
Git feil nr. 4: Du slettet ved en feiltakelse en gren
Her er et scenario vi alle gruer oss til: ved et uhell sletter en hel gren fra depotet vårt. Denne kan være veldig lett å komme seg fra eller litt vanskeligere, avhengig av omstendighetene.
Bruk først git reflog for å finne den siste forpliktelsen til grenen. Bruk deretter hash-ID-en til å opprette en ny gren:
git kassa -b restaurert-gren
Vær oppmerksom på at dette bare vil friske baconet ditt hvis den aktuelle grenen allerede var slått sammen. Hvis du tvangsslettet en unmerged har du en måte å finne den til, forutsatt at du ikke har løpt git gc på depotet:
git fsck --full --no-reflogs --unreachable - tapt funnet
Dette vil dumpe en liste over alle kommisjonshashene for objekter som ikke lenger er tilgjengelige, inkludert slettede grener. Se fra bunnen av listen opp for en "unreachable commit" -oppføring, og prøv å gjenopprette den hash-ID-en til en ny gren for å se om det er den du søppel. Hvis det ikke er det, kan du jobbe deg oppover til listen og se hva du kan gjenopprette.
Som en generell regel må du aldri tvinge til å slette en filial som standard, da du lett kan ende opp med å legge avfall til en ikke-sammenslått gren som fortsatt har noe verdifullt i seg. Hvis du vanligvis tvinger å slette grener, er det et tegn på at arbeidsvanene dine med grener må være mindre rotete.
Git feil nr. 5: Du kløvde den eksterne grenen med git push
En gang jobbet jeg med en lokal kopi av et GitHub-arkiv, og feilaktig presset hovedgrenen min til den eksterne kopien med --makt alternativ. Jeg endte med en offentlig kopi av en repo som ikke var i brukbar tilstand på den tiden. Store oops.
Hvis du har gjort en feil som dette, og repoen din ble synkronisert med den eksterne repoen nylig nok, kan du bruke din egen kopi av den eksterne repo-grenen for å fikse den. Bytt til grenen du trenger for å synkronisere på nytt, forutsatt at du ikke allerede er der, og gi denne kommandoen:
git reset --hard / @ {1}
Dette vil tilbakestille kopien av til den siste synkroniserte versjonen av . I mitt tilfelle var grenen herre og den eksterne repoen var opprinnelse, så jeg kunne ha brukt git reset - hard origin / master @ {1}.
Bruk deretter git push -f for å gjenopprette det eksterne lageret til sin tidligere tilstand.
En måte å forhindre at dette skjer igjen, er å ikke tillate pressing. Du kan konfigurere dette på den eksterne Git repo med denne kommandoen:
git config - system receive.denyNonFastForwards sant
Det kan komme en tid da du trenger å presse, men det er sannsynligvis best å slå dette på når du trenger det og av når du ikke trenger det.
Git feil nr. 6: Du begikk privat informasjon til en offentlig repo
Dette kan være det verste og vanskeligste Git-problemet å håndtere. Du har feilaktig begått sensitive data til en offentlig repo, og du vil kirurgisk avgifte filene fra repoen. Du må sørge for at sensitive data ikke blir funnet selv ved å gå tilbake til en tidligere forpliktelse, men du må gjøre detuten å berøre noe annet.
Dette er dobbelt vanskelig hvis den aktuelle filen ble begått, åh, for seks uker siden, og en lastebil med annet viktig arbeid har blitt begått i mellomtiden. Du kan ikke bare rulle tilbake til før filen ble lagt til; du vil ødelegge alt annet i prosessen.
Den gode nyheten: Noen få fryktløse Git-mavens opprettet et verktøy, BFG Repo-Cleaner, spesielt for å fjerne dårlige data fra Git repos. BFG Repo-Cleaner lar deg raskt utføre vanlige oppgaver på en repo, for eksempel å fjerne alle filer som samsvarer med et bestemt jokertegn eller inneholder bestemte tekster. Du kan til og med sende inn en fil som viser alle de uønskede tekstene.
BFG Repo-Cleaner er egentlig automatisering for en flertrinnsprosess ved bruk git filter-gren. Hvis du heller vil gjøre ting for hånd, har GitHub en detaljert gjennomgang av prosessen. Men BFG-verktøyet dekker de aller fleste vanlige brukssaker, hvorav mange er bakt inn i verktøyets kommandolinjealternativer. I tillegg er prosessen lang og kompleks, og det er altfor lett å skyte seg i foten et sted underveis hvis du gjør det for hånd.
Vær oppmerksom på at hvis du renser data fra en lokal filial som må synkroniseres andre steder, vil du ikke kunne synkronisere bortsett fra ved å tvinge dem til de eksterne grenene. Hele kommittetreet må skrives om, så du skriver i hovedsak en helt ny historie til fjernkontrollen. Du må også sørge for at alle andre henter en fersk kopi av den omskrevne repoen etter endringene dine, fordi repoer ikke lenger er gyldige.
