Velkým důvodem, proč vývojáři používají systém pro řízení zdrojů, jako je Git, je zabránit katastrofám. Pokud uděláte něco tak jednoduchého, jako je omylem smazat soubor, nebo zjistíte, že všechny změny provedené v tuctu souborů byly neuvážené, můžete s malými potížemi vrátit zpět to, co jste provedli.
Některé chyby Git jsou více zastrašující a obtížné je zvrátit, dokonce i pro zkušené uživatele Git. Ale s trochou opatrnosti - a za předpokladu, že nepanikaříte - se můžete vrátit zpět od těch nejhorších katastrof Git, které programátoři znají.
Zde je seznam několika větších boo-boosů Git spolu s tipy, jak z nich vycouvat a zabránit některým z nich. Čím dále se v seznamu dostanete, tím větší jsou katastrofy.
Git error # 1: Zapomněli jste přidat změny do posledního potvrzení
Toto je jeden z nejjednodušších omylů Git, ze kterého se vzpamatovali. Řekněme, že jste se zavázali nějakou práci na místní pobočce, a pak jste si uvědomili, že jste nevytvořili řadu potřebných souborů. Nebo jste zapomněli přidat určité podrobnosti do zprávy o potvrzení.
Žádný strach. Nejprve, pokud máte k dispozici nové změny, proveďte to. Poté zadejte git commit --amend upravit zprávu potvrzení. Až budete hotovi, stiskněte Esc a zadejte : xq uložit a opustit editor. (Tento poslední krok je ten, který často zaměňuje nováčky Git, kteří si vždy neuvědomují, že vestavěný editor Git je do značné míry jeho vlastní zvíře.)
Pokud právě měníte soubory a nepotřebujete upravovat zprávu o potvrzení, můžete použít git commit --amend --no-edit přidat soubory a přeskočit proces úpravy zprávy.
Jedním ze způsobů, jak se tomuto druhu chyb vyhnout, je vyladit způsob, jakým provádíte závazky v Gitu. Pokud pracujete na něčem, kde neustále provádíte malé závazky ke sledování přírůstkových revizí, udělejte to v jednorázové větvi. Když to uděláte, zdokumentujte hlavní změny, které někde provádíte - nečekejte, až se setkáte s git commit příkazový řádek, abyste si to všechno zapsali. Poté, když dosáhnete významného milníku, použijte git merge - squash z vaší jednorázové větve, abyste uložili výsledky do větve probíhající práce jako jediný, čistý revizi, a použijte poznámky, které jste si vzali pro revizní zprávu.
Git chyba č. 2: Provedli jste změny (místního) pána
Další obyčejný pitomec: Vědomě jste se dopustili spousty změn ... ale omylem do hlavní větve vašeho repo. Co ty opravdu chtěl udělat, bylo zavázat je k Nový pobočka, nebo k tomu dev větev, kterou máte konkrétně pro přerušení změn.
Vše není ztraceno. Tuto chybu lze opravit ve třech příkazech:
git větev new-branchgit reset HEAD ~ --hard
git checkout new-branch
První příkaz vytvoří novou větev, se kterou chceme pracovat. Druhý příkaz resetuje hlavní větev na těsně před posledním potvrzením, ale ponechá změny, které jste právě provedli v Nový větev. Nakonec přejdeme do nové pobočky, kde na vás čekají změny.
Pokud jste provedli více závazků, použijte git reset HEAD ~ --hard, kde je počet závazků zpět, které chcete použít. Nebo můžete použít git reset , kde je hash ID cílového potvrzení, pokud ho máte po ruce.
Chcete-li se této chybě vyhnout, zvykněte si vytvářet nové větve a přepínat na ně, i když budou zlikvidovány, kdykoli začnete žádný relace s vaším kódem.
Git error # 3: Zničili jste soubor nebo adresář
Další běžnou katastrofou je omylem rozbití obsahu souboru ... a jen když se o ní dozvíte, mnoho se zaváže k větvi po skutečnost. Naštěstí existuje snadná oprava.
Nejprve použijte git log nebo integrované nástroje Git vašeho IDE pro nalezení hash ID pro potvrzení z doby před úpravou souboru. Dále použijte git checkout hash_id - / cesta / k / souboru zkontrolovat pouze ten soubor z dotyčného potvrzení. Všimněte si, že cesta by měla být relativní ke kořenu projektu. Tím umístíte dřívější verzi souboru do pracovní oblasti projektu.
Pokud se chcete jednoduše vrátit n zaváže, nepotřebujete hash ID. Stačí zadat příkaz git checkout HEAD ~ - / cesta / k / souboru, kde je počet závazků zpět, které chcete použít.
Pokud si chcete prohlédnout celý adresář souborů, pak pro cesty k souborům použijte zástupný formát Gitu. Například zadávánípokladna git HEAD ~ 1 - ./src/** vás vezme zpět jeden spáchat a obnovit vše v / src z kořenového adresáře projektu.
Chyba Git č. 4: Omylem jste odstranili větev
Tady je scénář, kterého se všichni bojíme: náhodného smazání celé větve z našeho úložiště. Z toho může být buď velmi snadné se vzpamatovat, nebo trochu složitější, v závislosti na okolnostech.
Nejprve použijte git reflog najít poslední potvrzení provedené na pobočce. Potom použijte hash ID k vytvoření nové větve:
git checkout -b obnovena-větev
Pamatujte, že to vaši slaninu odpeče, pouze pokud byla příslušná větev již sloučena. Pokud jste vynutili smazání nespojené větev, máte ještě jeden způsob, jak ji najít, pokud jste neběhli git gc v úložišti:
git fsck --full --no-reflogs - nedostupný --lost-found
Tím se vypíše seznam všech hodnot hash potvrzení pro objekty, které již nejsou dostupné, včetně odstraněných větví. Vyhledejte v dolní části seznamu položku „nedosažitelného potvrzení“ a zkuste obnovit toto hash ID do nové větve, abyste zjistili, zda je to ta, kterou jste vyhodili do koše. Pokud tomu tak není, přepracujte se v seznamu na další a podívejte se, co můžete obnovit.
Obecně platí, že větev ve výchozím nastavení nikdy nevymažte, protože byste mohli snadno skončit s ukládáním odpadu do nesloučené větve, která v sobě stále má něco cenného. Pokud obvykle vynucujete mazání větví, znamená to, že vaše pracovní návyky s větvemi musí být méně chaotické.
Chyba Git č. 5: Vzdálili jste vzdálenou větev pomocí git push
Jednou jsem pracoval na místní kopii úložiště GitHub a omylem jsem tlačil svou hlavní větev na vzdálenou kopii pomocí --platnost volba. Skončil jsem s veřejnou kopií repo, která v té době nebyla v použitelném stavu. Velký oops.
Pokud jste udělali takovou chybu a vaše repo bylo nedávno synchronizováno se vzdáleným repo, můžete to opravit pomocí vlastní kopie pobočky vzdáleného repo. Přepněte na větev, kterou potřebujete znovu synchronizovat, za předpokladu, že tam ještě nejste, a zadejte tento příkaz:
git reset --hard / @ {1}
Tím se obnoví vaše kopie souboru na poslední synchronizovanou verzi . V mém případě byla pobočka mistr a vzdálené repo bylo původ, takže jsem mohl použít git reset --hard origin / master @ {1}.
Pak použijte git push -f obnovit vzdálené úložiště do předchozího stavu.
Jedním ze způsobů, jak zabránit tomu, aby se to opakovalo, je zakázat tlačení silou. Můžete to nakonfigurovat na vzdáleném Git repo pomocí tohoto příkazu:
git config --system receive.denyNonFastForwards true
Může přijít čas, kdy budete muset stisknout sílu, ale pravděpodobně je nejlepší si to zapnout, když to potřebujete, a vypnout, když to nepotřebujete.
Chyba Git č. 6: Zadali jste soukromé informace veřejnému repo
To může být nejhorší a nejobtížnější problém Gitu, se kterým se můžete vypořádat. Omylem jste spáchali citlivá data ve veřejném repo a chcete soubory z repozitáře chirurgicky vyříznout. Musíte se ujistit, že citlivá data nelze najít ani návratem k dřívějšímu potvrzení, ale musíte to udělataniž byste se dotkli čehokoli jiného.
To je dvojnásob obtížné, pokud byl dotyčný spis spáchán před šesti týdny a mezitím byl spáchán náklad dalších důležitých prací. Před přidáním souboru se nemůžete vrátit zpět; zničíte všechno ostatní v tomto procesu.
Dobrá zpráva: Několik neohrožených Git mavenů vytvořilo nástroj, BFG Repo-Cleaner, konkrétně za účelem odstranění špatných dat z repozitářů Git. BFG Repo-Cleaner vám umožňuje rychle provádět běžné úkoly v repo, jako je odstranění všech souborů odpovídajících konkrétnímu zástupnému znaku nebo obsahujících určité texty. Můžete dokonce předat soubor se seznamem všech nežádoucích textů.
BFG Repo-Cleaner je v podstatě automatizace pro použití vícekrokového procesu git filtrační větev. Pokud byste raději dělali věci ručně, má GitHub podrobný návod na postup. Nástroj BFG ale pokrývá drtivou většinu běžných případů použití, z nichž mnohé jsou vloženy do možností příkazového řádku nástroje. Tento proces je navíc dlouhý a složitý a je příliš snadné střelit si někde podél cesty, pokud to děláte ručně.
Všimněte si, že pokud čistíte data z místní větve, kterou je třeba synchronizovat jinde, nebudete ji moci synchronizovat jinak než vynuceným zasunutím do vzdálených větví. Celý strom odevzdání musí být přepsán, takže v podstatě píšete na ovladači úplně novou historii. Budete také muset zajistit, aby všichni ostatní po vašich změnách vytáhli novou kopii přepsaného repo, protože jejich repozitáře již nebudou platné.
