Svarbi priežastis, kodėl kūrėjai naudoja tokią šaltinių valdymo sistemą kaip „Git“, yra vengti nelaimių. Jei padarysite kažką tokio paprasto, kaip klaidingai ištrinsite failą, arba pastebėsite, kad keliolikoje failų atlikti pakeitimai buvo nepatartini, galite be vargo anuliuoti tai, ką padarėte.
Kai kurios „Git“ klaidos yra bauginančios ir jas sunku pakeisti net patyrusiems „Git“ vartotojams. Tačiau šiek tiek atsargiai - ir jei nepanikuojate - galite atsigauti nuo pačių blogiausių „Git“ katastrofų, kurias žino programuotojai.
Čia yra keletas didesnių „Git boo-boos“ sąrašas kartu su patarimais, kaip atsisakyti jų ir užkirsti kelią kai kuriems iš jų. Kuo toliau žemyn sąraše, tuo didesnės nelaimės.
1 klaida: pamiršote pridėti pakeitimų prie paskutinio įsipareigojimo
Tai yra viena iš lengviausių „Git“ klaidų, kurias galima atsigauti. Tarkime, kad atlikote tam tikrą darbą vietos skyriui, tada supratote, kad nesudarėte daugybės reikalingų failų. Arba pamiršote pridėti tam tikrą informaciją į įsipareigojimo pranešimą.
Be baimės. Pirma, jei turite naujus pakeitimus, atlikite tai. Tada įveskite git įsipareigoti - pakeisti redaguoti įsipareigojimo pranešimą. Baigę paspauskite Esc, tada įveskite : xq išsaugoti ir išeiti iš redaktoriaus. (Šis paskutinis žingsnis dažnai sujaudina „Git“ naujokus, kurie ne visada supranta, kad įmontuotas „Git“ redaktorius labai yra jo paties gyvūnas.)
Jei tik keičiate failus ir nereikia keisti įsipareigojimo pranešimo, galite naudoti git įsipareigoti - pakeisti - ne-redaguoti norėdami pridėti failus ir praleisti pranešimo redagavimo procesą.
Vienas iš būdų išvengti tokios klaidos yra pakoreguoti tai, kaip darote įsipareigojimus „Git“. Jei dirbate dėl kažko, kur nuolat prisiimate nedidelius įsipareigojimus stebėti palaipsniui atliekamus pakeitimus, atlikite juos išmetimo skyriuje. Tai atlikdami dokumentuokite pagrindinius kažkur daromus pakeitimus - nelaukite, kol susidursite su git įsipareigoti komandinė eilutė, kad viską užrašytumėte. Tada, kai pasieksite svarbiausią etapą, naudokite git sulieti - skvošas iš savo išmetamo filialo, kad išsaugotumėte rezultatus nebaigtos gamybos skyriuje kaip vieną, švarų įsipareigojimą ir naudokite užrašus, kuriuos atlikote įsipareigojimo pranešimui.
2 klaida: atlikote pakeitimus (vietiniam) meistrui
Kitas įprastas dalykas: jūs pareigingai atlikote daugybę pakeitimų ... bet per savo atpirkimo meistrą per klaidą. Ką tu tikrai norėjo padaryti, tai juos įpareigoti a naujas filialas, arba prie to dev filialas, kurį turite specialiai tam, kad sugadintumėte pokyčius.
Viskas nėra prarasta. Šią klaidą galima ištaisyti trimis komandomis:
git filialas naujas-filialasgit reset HEAD ~ - sunku
git checkout new-filialas
Pirmoji komanda sukuria naują filialą, su kuriuo norime dirbti. Antroji komanda atkuria pagrindinę šaką prieš pat paskutinį įsipareigojimą, tačiau palieka ką tik atliktus pakeitimus naujas atšaka. Galiausiai pereiname į naują skyrių, kur jūsų laukia jūsų pokyčiai.
Jei atlikote kelis įsipareigojimus, naudokite git reset HEAD ~ - sunku, kur yra atgalinių įsipareigojimų, kuriuos norite atlikti, skaičius. Arba galite naudoti git atstatyti , kur yra tikslinio įsipareigojimo maišos ID, jei turite tokį patogu.
Norėdami išvengti šios klaidos, įpraskite kurti naujas šakas ir pereiti prie jų, net jei jie tik bus išmesti, kai tik pradėsite bet koks sesija su savo kodu.
Git klaida Nr. 3: jūs išmėtėte failą ar katalogą
Kita dažnai pasitaikanti nelaimė yra klaidingas failo turinio išmėtymas ... ir tik sužinoję apie tai daugelis įsipareigoja filialui po to faktas. Laimei, tai lengva išspręsti.
Pirma, naudokite git žurnalas arba jūsų IDE įmontuotą „Git“ įrankį, kad rastumėte maišos ID, skirtą įvykdyti dar prieš failo modifikavimą. Tada naudokite git checkout hash_id - / kelias / į / failą Patikrinti tik tą bylą iš nagrinėjamo įsipareigojimo. Atminkite, kad kelias turėtų būti lyginamas su projekto šaknimi. Tai padės ankstesnę failo versiją į jūsų projekto sritį.
Jei tiesiog norite grįžti atgal n įsipareigoja, jums nereikia maišos ID. Galite tiesiog išduoti komandą git checkout HEAD ~ - / kelias / į / failas, kur yra atgalinių įsipareigojimų, kuriuos norite atlikti, skaičius.
Jei norite patikrinti visumą kataloge failų, tada failų keliams naudokite pakaitos simbolius „Git“. Pavyzdžiui, įeinantgit kasa HEAD ~ 1 - ./src/** grąžins jums vieną įsipareigojimą ir viską atgausite / src katalogą iš savo projekto šaknies.
4 klaida: netyčia ištrynėte šaką
Štai scenarijus, kurio visi bijome: netyčia ištrynę visą filialą iš savo saugyklos. Tai gali būti labai lengva atsigauti arba šiek tiek kebliau, atsižvelgiant į aplinkybes.
Pirma, naudokite git reflog rasti paskutinį filialui padarytą įsipareigojimą. Tada naudokite maišos ID, kad sukurtumėte naują filialą:
git kasa -b atkurta-filialas
Atminkite, kad tai pašalins jūsų lašinius tik tuo atveju, jei atitinkamas šakas jau buvo sujungtas. Jei priverstinai ištrinsite an neprisirišęs filialą, turite dar vieną būdą jį rasti, jei dar nepabėgote git gc saugykloje:
git fsck --full --no-reflogs - nepasiekiamas --rastas
Tai išmes visų atliktų maišų sąrašą objektams, kurių nebepasiekiama, įskaitant ištrintas šakas. Iš sąrašo apačios ieškokite įrašo „nepasiekiamas įsipareigojimas“ ir pabandykite atkurti tą maišos ID naujame filiale, kad pamatytumėte, ar jis buvo šiukšliadėžėje. Jei taip nėra, eikite į kitą sąrašą ir sužinokite, ką galite atkurti.
Paprastai pagal numatytuosius nustatymus niekada neverskite šakos iš prievartos, nes galite lengvai padėti atliekas ant nesusijusios šakos, kurioje vis dar yra kažkas vertingo. Jei paprastai jėga ištrinate šakas, tai rodo, kad jūsų darbo įpročiai su šakomis turi būti mažiau netvarkingi.
5 klaida: Jūs apiplėšėte nuotolinį filialą git stumti
Kartą dirbau su „GitHub“ saugyklos vietine kopija ir per klaidą pastūmėjau savo pagrindinį filialą į nuotolinę kopiją. - jėga variantą. Pabaigiau viešą repo kopiją, kuri tuo metu nebuvo tinkama naudoti. Didelis opas.
Jei padarėte tokią klaidą ir jūsų repo buvo pakankamai neseniai sinchronizuotas su nuotolinio atpirkimo operacija, galite ją išspręsti naudodami savo nuotolinio atpirkimo filialo kopiją. Perjunkite į filialą, kurį reikia iš naujo sinchronizuoti, darant prielaidą, kad dar nesate, ir išleiskite šią komandą:
„git reset“ - sunku / @ {1}
Tai iš naujo nustatys jūsų kopiją į paskutinę sinchronizuotą . Mano atveju filialas buvo meistras o nuotolinis repo buvo kilmę, todėl galėjau naudoti „git“ atstatymas - sunki kilmė / pagrindinis @ {1}.
Tada naudokite git push -f atkurti nuotolinės saugyklos ankstesnę būseną.
Vienas iš būdų užkirsti kelią tam, kad tai nepasikartotų, yra neleisti stumti jėgos. Tai galite sukonfigūruoti nuotoliniame „Git“ repo naudodami šią komandą:
git config --sistema gauti.denyNonFastForwards true
Gali ateiti laikas, kai jums reikia atlikti jėgos pastūmimą, bet tikriausiai geriausia tai įjungti, kai jums to reikia, ir išjungti, kai to nereikia.
Git klaida Nr. 6: privataus pobūdžio informaciją skyrėte viešam atpirkimo sandoriui
Tai gali būti blogiausia ir sunkiausia spręsti „Git“ problemą. Klaidingai paskyrėte neskelbtinus duomenis viešai atpirkimo operacijai ir norite chirurginiu būdu iškirpti failus iš atpirkimo. Turite įsitikinti, kad neskelbtinų duomenų negalima rasti net grįžus prie ankstesnio įsipareigojimo, tačiau jūs turite tai padarytinieko daugiau neliesdamas.
Tai yra dvigubai sunku, jei nagrinėjama byla buvo padaryta, oi, prieš šešias savaites, o tuo tarpu buvo atliktas sunkvežimis kitų svarbių darbų. Negalite tiesiog grįžti prie failo pridėjimo; proceso metu sužlugdysi visa kita.
Geros naujienos: Keletas bebaimių „Git Mavens“ sukūrė įrankį „BFG Repo-Cleaner“, specialiai tam, kad pašalintų blogus duomenis iš „Git“ repo. „BFG Repo-Cleaner“ leidžia greitai atlikti įprastas atpirkimo operacijas, pvz., Pašalinti visus failus, atitinkančius tam tikrą pakaitos simbolį arba turinčius tam tikrus tekstus. Jūs netgi galite perduoti failą, kuriame išvardyti visi nepageidaujami tekstai.
„BFG Repo-Cleaner“ iš esmės yra daugiapakopio proceso automatizavimas git filtras-atšaka. Jei norėtumėte viską atlikti rankomis, „GitHub“ pateikia išsamų proceso aprašymą. Tačiau BFG įrankis apima didžiąją daugumą įprasto naudojimo atvejų, iš kurių daugelis yra įtraukiami į įrankio komandinės eilutės parinktis. Be to, procesas yra ilgas ir sudėtingas, ir per daug lengva nušauti sau koją pakeliui, jei tai darai ranka.
Atminkite, kad jei išvalysite duomenis iš vietinio filialo, kuris turi būti sinchronizuojamas kitur, negalėsite sinchronizuoti, išskyrus jėgos pastangas į nuotolinius filialus. Turi būti perrašytas visas įsipareigojimų medis, todėl iš esmės jūs rašote visiškai naują istoriją nuotoliniu būdu. Taip pat turėsite įsitikinti, kad visi kiti po jūsų pakeitimų išsitraukia naują perrašyto repo kopiją, nes ir jų repo nebegalios.
