Programiranje

6 Git napake, ki jih boste naredili - in kako jih odpraviti

Velik razlog, da razvijalci uporabljajo sistem za nadzor virov, kot je Git, je, da se izognejo nesrečam. Če naredite nekaj tako preprostega, kot da pomotoma izbrišete datoteko, ali odkrijete, da so bile spremembe v ducat datotekah vse nepremišljene, lahko z malo težav razveljavite to, kar ste storili.

Nekatere napake Git so bolj zastrašujoče in jih je težko popraviti, tudi za izkušene uporabnike Gita. Toda z nekaj previdnosti - in pod pogojem, da ne boste prestrašeni - se lahko odvrnete od nekaterih najhujših katastrof Git, ki jih poznajo programerji.

Tu je seznam večjih Git boo-boo-jev, skupaj z nasveti za njihovo ukinitev in preprečevanje nekaterih od njih. Čim dlje se spuščate po seznamu, tem večje so nesreče.

Napaka Git # 1: Pozabili ste dodati spremembe v zadnji objavi

To je ena najlažjih napak pri Gitu, ki si jo lahko opomorete. Recimo, da ste nekaj dela namenili lokalni podružnici, nato pa ugotovili, da niste uprizorili številnih potrebnih datotek. Ali pa ste pozabili dodati določene podrobnosti v sporočilu za objavo.

Brez strahu. Najprej, če imate nove spremembe za izvedbo, to storite. Nato vnesite git commit --amend za urejanje sporočila o objavi. Ko končate, pritisnite Esc in nato vnesite : xq shranite in zapustite urejevalnik. (Ta zadnji korak je tisti, ki pogosto zmoti novince v Gitu, ki se ne zavedajo vedno, da je vgrajeni urejevalnik Git zelo velika žival.)

Če samo spreminjate datoteke in vam ni treba spremeniti sporočila o prevzemu, lahko uporabite git commit --amend --no-edit da dodate datoteke in preskočite postopek urejanja sporočil.

Eden od načinov, kako se izogniti tovrstnim napakam, je prilagoditi način, kako se zavezujete v Gitu. Če delate na nečem, pri čemer nenehno izvajate majhne zaveze za sledenje postopnim revizijam, jih naredite v vrnjeni veji. Ko to počnete, dokumentirajte glavne spremembe, ki jih nekje naredite - ne čakajte, dokler se ne soočite z git commit ukazno vrstico, da vse zapišete. Potem, ko dosežete pomemben mejnik, uporabite git merge --squash iz podrejene veje, da rezultate shranite v nedokončano vejo kot en sam, čist prevzem in uporabite zapiske, ki ste jih naredili za sporočilo o prevzemu.

Git error # 2: Spremenili ste spremembe v (lokalnem) masterju

Še ena pogosta potegavščina: Vljudno ste izvedli kopico sprememb ... vendar v pomožni veji vašega repoja. Kaj ti res želel je, da jih zavežejo k novo podružnico ali na to razv vejo, ki jo imate posebej za razbijanje sprememb.

Vse ni izgubljeno. To napako lahko odpravite v treh ukazih:

git podružnica nova veja

git reset HEAD ~ --trdo

git checkout nova veja

Prvi ukaz ustvari novo vejo, s katero želimo delati. Drugi ukaz ponastavi glavno vejo na tik pred zadnjo odobritvijo, vendar zapusti spremembe, ki ste jih pravkar izvedli v novo podružnica. Končno preidemo na novo vejo, kjer vas čakajo vaše spremembe.

Če ste izvedli več prevzemov, uporabite git reset HEAD ~ --trdo, kje je število povratnih prevzemov, ki jih želite opraviti. Ali pa lahko uporabite ponastavitev gita , kje je ID razpršitve ciljnega predaja, če imate to priročno.

Da bi se izognili tej napaki, si vzemite navado, da vsakič, ko začnete, izdelujete nove veje in preklopite nanje, tudi če bodo le zavržene. kaj sejo s svojo kodo.

Git error # 3: Odstranili ste datoteko ali imenik

Druga pogosta katastrofa je pomotoma odstranjevanje vsebine datoteke ... in če o njej izvemo šele, se veliko pošlje v podružnico po dejstvo. Na srečo obstaja enostaven popravek.

Najprej uporabite git log ali vgrajeno orodje Git za IDE, da poišče ID razpršitve za objavo pred spremembo datoteke. Nato uporabite git checkout hash_id - / pot / do / datoteke pregledati samo datoteko iz zadevne odobritve. Upoštevajte, da mora biti pot sorazmerna korenu projekta. S tem bo prejšnja različica datoteke postavljena na odrsko območje vašega projekta.

Če se preprosto želite vrniti n se zaveže, ne potrebujete razpršenega ID-ja. Lahko samo izdate ukaz git checkout HEAD ~ - / pot / do / datoteke, kje je število povratnih prevzemov, ki jih želite opraviti.

Če želite preveriti celoto imenik datotek, nato za poti datotek uporabite Gitov nadomestni format. Na primer, vstopgit checkout HEAD ~ 1 - ./src/** vas bo popeljal nazaj en prevzem in povrnil vse v / src iz korena vašega projekta.

Git error # 4: Nehote ste izbrisali vejo

Tukaj je scenarij, ki se ga vsi bojimo: nenamerno izbrišete celotno vejo iz našega skladišča. Ta je lahko zelo enostaven za ozdravitev ali nekoliko bolj zapleten, odvisno od okoliščin.

Najprej uporabite git reflog poiskati zadnjo obveznost, podano podružnici. Nato uporabite ID razpršitve, da ustvarite novo vejo:

git checkout -b obnovljena-veja

Upoštevajte, da boste slanino spekli le, če je bila zadevna veja že združena. Če prisilno izbrišete nepotopljeno podružnico, imate še en način, da jo najdete, če še niste kandidirali git gc na odlagališču:

git fsck --full --no-reflogs --unchachable - lost-found

S tem bo izpisan seznam vseh zgoščenih datotek za predmete, ki niso več dosegljivi, vključno z izbrisanimi vejami. Na dnu seznama poiščite vnos »nedosegljiva obveza« in poskusite obnoviti ta ID razpršitve v novo vejo, da preverite, ali je tisto, ki ste ga premagali. Če ni, pojdite na seznam do naslednjega in poglejte, kaj lahko obnovite.

Praviloma vej nikoli ne privzeto brišite na silo, saj lahko zlahka odložite odpadke na nepovezano vejo, v kateri je še nekaj dragocenega. Če običajno veje brišete na silo, je to znak, da morajo biti vaše delovne navade s podružnicami manj neurejene.

Git error # 5: Z oddaljeno vejo ste prekrili git push

Ko sem delal na lokalni kopiji repozitorija GitHub in pomotoma potisnil svojo glavno vejo na oddaljeno kopijo z - sila možnost. Končal sem z javno kopijo repoja, ki takrat ni bil v uporabnem stanju. Velika ups.

Če ste storili takšno napako in je bil vaš repo sinhroniziran z oddaljenim repoom pred kratkim, lahko to popravite s svojo kopijo oddaljene repo veje. Preklopite na vejo, ki jo morate znova sinhronizirati, ob predpostavki, da še niste, in izdajte ta ukaz:

git reset --hard / @ {1}

S tem boste ponastavili svojo kopijo do zadnje sinhronizirane različice . V mojem primeru je bila podružnica mojster in oddaljeni repo je bil porekla, tako da bi lahko uporabil git reset --hard origin / master @ {1}.

Nato uporabite git push -f za obnovitev oddaljenega repozitorija v prejšnje stanje.

Eden od načinov, da se to ne ponovi, je, da onemogočite potiskanje sile. To lahko nastavite na oddaljenem repozitoriju Git s tem ukazom:

git config --system receive.denyNonFastForwards true

Morda bo prišel čas, ko boste morali pritisniti na silo, vendar je verjetno najbolje, da to vklopite, ko ga potrebujete, in izklopite, ko ga ne.

Git error # 6: Zasebne podatke ste predali javnemu repo računu

To je lahko najslabši in najtežji Gitov problem. Občutljive podatke ste pomotoma predali javnemu repoju in želite kirurško izrezati datoteke iz repoja. Prepričati se morate, da občutljivih podatkov ni mogoče najti niti tako, da se vrnete na prejšnjo odobritev, vendar morate to storitine da bi se dotaknili česar koli drugega.

To je dvojno težko, če je bila zadevna datoteka predana, oh, pred šestimi tedni, medtem pa je bilo opravljeno še veliko drugih pomembnih del. Ne morete se samo vrniti nazaj, preden je bila datoteka dodana; v procesu boste uničili vse ostalo.

Dobra novica: Nekaj ​​neustrašnih Git mavenov je ustvarilo orodje, BFG Repo-Cleaner, posebej za namen odstranjevanja slabih podatkov iz Git repo-jev. BFG Repo-Cleaner vam omogoča hitro izvajanje običajnih nalog v repo, na primer odstranitev vseh datotek, ki se ujemajo z določenim nadomestnim znakom ali vsebujejo določena besedila. Lahko celo prenesete datoteko, ki vsebuje vsa neželena besedila.

BFG Repo-Cleaner je v bistvu avtomatizacija za večstopenjski postopek git filter-veja. Če raje stvari počnete ročno, ima GitHub podroben potek postopka. Toda orodje BFG zajema veliko večino primerov običajne uporabe, od katerih so mnogi vključeni v možnosti ukazne vrstice orodja. Poleg tega je postopek dolg in zapleten, vse preveč pa je, da si nekje na poti ustrelite nogo, če to počnete ročno.

Če iz lokalne veje očistite podatke, ki jih je treba sinhronizirati drugje, jih ne boste mogli sinhronizirati, razen s pritiskom na silo do oddaljenih vej. Celotno drevo odobritev je treba prepisati, tako da v bistvu na daljavo pišete povsem novo zgodovino. Prav tako boste morali poskrbeti, da bodo vsi ostali po vaših spremembah potegnili novo kopijo prepisanega repo, ker tudi njihovi repo skladi ne bodo več veljavni.

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