Programmering

6 Git-fejl, du laver - og hvordan man løser dem

En stor grund til, at udviklere bruger et kildekontrolsystem som Git, er at undgå katastrofer. Hvis du gør noget så simpelt som fejlagtigt at slette en fil, eller hvis du opdager, at de ændringer, du har foretaget i et dusin filer, alle var dårlige, kan du fortryde, hvad du har gjort med lidt besvær.

Nogle Git-fejl er mere skræmmende og vanskelige at vende, selv for erfarne Git-brugere. Men med lidt omhu - og forudsat at du ikke får panik - kan du rulle tilbage fra nogle af de værste Git-katastrofer, som programmører kender.

Her er en liste over flere af de større Git boo-boos sammen med tip til at bakke ud af dem og forhindrer nogle af dem. Jo længere du går ned på listen, jo større bliver katastroferne.

Git fejl nr. 1: Du har glemt at tilføje ændringer til den sidste forpligtelse

Dette er en af ​​de nemmeste Git-tabber at komme sig fra. Lad os sige, at du har gjort noget for en lokal filial og derefter indså, at du ikke iscenesatte et antal nødvendige filer. Eller du glemte at tilføje visse detaljer i meddelelsen.

Ingen frygt. For det første, hvis du har nye ændringer, der skal iscenesættes, skal du gøre det. Skriv derefter git commit --ændre for at redigere forpligtelsesmeddelelsen. Når du er færdig, skal du trykke på Esc og derefter skrive : xq for at gemme og afslutte editoren. (Dette sidste trin er det, der ofte forvirrer Git-nykommere, som ikke altid er klar over, at den indbyggede Git-editor meget er sit eget dyr.)

Hvis du bare skifter filer, og du ikke har brug for at ændre forpligtelsesmeddelelsen, kan du bruge git commit --amend --no-edit for at tilføje filerne og springe beskedredigeringsprocessen over.

En måde at undgå denne form for fejl er at tilpasse den måde, du forpligter dig til i Git. Hvis du arbejder på noget, hvor du konstant forpligter dig til at spore trinvise ændringer, skal du gøre dem i en smidende gren. Når du gør dette, skal du dokumentere de store ændringer, du foretager et eller andet sted - vent ikke, indtil du står over for git begå kommandolinje for at skrive det hele ned. Brug derefter, når du når en stor milepæl git merge - squash fra din kasserede filial for at gemme resultaterne til den igangværende filial som en enkelt, ren forpligtelse, og brug de noter, du har taget til forpligtelsesmeddelelsen.

Git fejl nr. 2: Du har begået ændringer til (lokal) master

Et andet almindeligt klods: Du har pligtopfyldt begået en masse ændringer ... men til mestergrenen for din repo ved en fejltagelse. Hvad du virkelig ville gøre var at forpligte dem til en ny gren eller til det dev gren, du har specifikt til at bryde ændringer.

Alt er ikke tabt. Denne fejl kan løses i tre kommandoer:

git gren ny gren

git reset HEAD ~ --hard

git checkout new-branch

Den første kommando opretter den nye gren, vi vil arbejde med. Den anden kommando nulstiller hovedgrenen til lige før den sidste forpligtelse, men efterlader de ændringer, du lige har foretaget i ny afdeling. Endelig skifter vi til den nye gren, hvor dine ændringer venter på dig.

Hvis du har foretaget flere forpligtelser, skal du bruge git reset HEAD ~ --hard, hvor er antallet af forpligtelser tilbage, du vil gå. Eller du kan bruge git reset , hvor er hash-ID'et for målforpligtelsen, hvis du har det praktisk.

For at undgå denne fejl skal du være vant til at oprette nye grene og skifte til dem, selvom de bare bliver kasseret, når du begynder nogen session med din kode.

Gitfejl nr. 3: Du smadrede en fil eller et bibliotek

En anden almindelig katastrofe er ved fejlagtigt at trash indholdet af en fil ... og kun finde ud af om det mange forpligter sig til filialen efter faktummet. Heldigvis er der en let løsning.

Brug først git log eller din IDE's indbyggede Git-værktøj til at finde hash-ID til en forpligtelse fra før filen blev ændret. Brug derefter git checkout hash_id - / sti / til / fil at tjekke ud kun denne fil fra den pågældende forpligtelse. Bemærk, at stien skal være i forhold til projektets rod. Dette placerer den tidligere version af filen i dit projekts iscenesættelsesområde.

Hvis du bare vil tilbage n forpligter sig, du behøver ikke hash-id'et. Du kan bare udstede kommandoen git checkout HEAD ~ - / sti / til / fil, hvor er antallet af forpligtelser tilbage, du vil gå.

Hvis du vil tjekke en hel vejviser af filer, og brug derefter Gits wildcard-format til filstier. For eksempel at indtastegit checkout HEAD ~ 1 - ./src/** vil tage dig tilbage en forpligtelse og gendanne alt i / src katalog fra roden til dit projekt.

Gitfejl nr. 4: Du slettede ved en fejltagelse en gren

Her er et scenarie, som vi alle frygter: ved et uheld at slette en hel gren fra vores lager. Denne kan være meget let at komme sig fra eller lidt mere vanskelig alt efter omstændighederne.

Brug først git reflog for at finde den sidste forpligtelse, der blev foretaget til filialen. Brug derefter hash-id'et til at oprette en ny gren:

git checkout -b restaureret gren

Bemærk, at dette kun frigør din bacon, hvis den pågældende filial allerede var fusioneret. Hvis du tvangssletter en unmerged filial, har du endnu en måde at finde den på, forudsat at du ikke har kørt git gc på arkivet:

git fsck --full --no-reflogs --unreachable - mistet fundet

Dette vil dumpe en liste over alle kommission hashes for objekter, der ikke længere er tilgængelige, inklusive slettede grene. Se fra bunden af ​​listen op efter en "uopnåelig forpligtelse" -post, og prøv at gendanne det hash-id i en ny gren for at se, om det er den, du har skraldet. Hvis det ikke er tilfældet, skal du arbejde dig op på listen til den næste og se, hvad du kan gendanne.

Som en generel regel må du aldrig tvinge til at slette en filial som standard, da du let kan ende med at lægge affald til en ikke-flettet gren, der stadig har noget værdifuldt i sig. Hvis du sædvanligvis tvinger sletning af grene, er det et tegn på, at dine arbejdsvaner med grene skal være mindre rodet.

Git fejl nr. 5: Du klodrede den fjerntliggende gren med git push

En gang arbejdede jeg på en lokal kopi af et GitHub-arkiv og skubbet fejlagtigt min mastergren til fjernkopien med --kraft mulighed. Jeg endte med en offentlig kopi af en repo, der ikke var i en brugbar tilstand på det tidspunkt. Store oops.

Hvis du har lavet en fejl som denne, og din repo blev synkroniseret med den eksterne repo for nylig nok, kan du bruge din egen kopi af den repo-filial til at rette den. Skift til den gren, du skal synkronisere igen, forudsat at du ikke allerede er der, og udgiv denne kommando:

git reset --hard / @ {1}

Dette nulstiller din kopi af til den sidst synkroniserede version af . I mit tilfælde var filialen mestre og den eksterne repo var oprindelse, så jeg kunne have brugt git reset - hård oprindelse / master @ {1}.

Brug derefter git push -f for at gendanne det eksterne lager til dets tidligere tilstand.

En måde at forhindre dette i at ske igen er at ikke tillade tvangsskubning. Du kan konfigurere dette på fjernbetjeningen Git repo med denne kommando:

git config - system receive.denyNonFastForwards sandt

Der kan komme et tidspunkt, hvor du har brug for at foretage et kraftudtryk, men det er sandsynligvis bedst at slå dette til, når du har brug for det, og af, når du ikke har det.

Git fejl nr. 6: Du begik private oplysninger til en offentlig repo

Dette kan være det værste og sværeste Git-problem at håndtere. Du har fejlagtigt begået følsomme data til en offentlig repo, og du vil kirurgisk afskære filerne fra repoen. Du skal sørge for, at de følsomme data ikke kan findes, selv ved at gå tilbage til en tidligere forpligtelse, men du skal gøre detuden at røre ved noget andet.

Dette er dobbelt hårdt, hvis den pågældende fil blev begået, åh, for seks uger siden, og der er blevet begået en lastbil med andet vigtigt arbejde i mellemtiden. Du kan ikke bare rulle tilbage til før filen blev tilføjet; du ødelægger alt andet i processen.

Den gode nyhed: Et par frygtløse Git mavens oprettede et værktøj, BFG Repo-Cleaner, specifikt med det formål at fjerne dårlige data fra Git repos. BFG Repo-Cleaner giver dig mulighed for hurtigt at udføre almindelige opgaver på en repo, f.eks. Fjerne alle filer, der matcher et bestemt jokertegn eller indeholder bestemte tekster. Du kan endda sende en fil, der viser alle de uønskede tekster.

BFG Repo-Cleaner er i det væsentlige automatisering til en flertrinsproces ved hjælp af git filter-gren. Hvis du hellere vil gøre ting i hånden, har GitHub en detaljeret gennemgang af processen. Men BFG-værktøjet dækker langt størstedelen af ​​almindelige brugssager, hvoraf mange er bagt ind i værktøjets kommandolinjemuligheder. Plus, processen er lang og kompleks, og det er alt for let at skyde dig selv i foden et eller andet sted undervejs, hvis du gør det manuelt.

Bemærk, at hvis du renser data fra en lokal filial, der skal synkroniseres andetsteds, vil du ikke være i stand til at synkronisere undtagen ved hjælp af et tvangstryk til de eksterne grene. Hele forpligtelsestræet skal omskrives, så du skriver i det væsentlige en helt ny historie til fjernbetjeningen. Du bliver også nødt til at sikre, at alle andre trækker en ny kopi af den omskrevne repo efter dine ændringer, fordi deres repos heller ikke længere er gyldige.

$config[zx-auto] not found$config[zx-overlay] not found