Aké sú bežné chyby Gitu a ako ich opraviť?



Pri verzovaní svojho kódu v systémovom nástroji na správu verzií git odstráňte najbežnejšie chyby a chráňte svoju integritu údajov.

S rozmachom tejto technológie bude nevyhnutné, aby každý IT pracovník pracoval na viacerých údajoch súčasne a vaše údaje sa neustále vyvíjajú. Je tiež nevyhnutné sledovať každú zmenu údajov a byť pripravený na prípadné vrátenie alebo vrátenie nežiaducich zmien.

Musím sa priznať, že verzia mojich údajov v Gite mi umožňuje experimentovať pri vývoji môjho projektu. Ak to pokazím, viem, že git má vždy spôsob, ako vrátiť späť alebo vrátiť túto verziu môjho projektu do pôvodného stavu pred tým, ako som to pokazil. Každý vrstva je navrhnutá tak, aby umožňovala zmeny údajov skontrolovať, upraviť a / alebo opraviť pred presunutím údajov v ďalšej fáze. Toto sú chyby, ktorým sa venuje tento blog:





Un-stage súbory / adresáre z indexu

Pri pridávaní a / alebo úprave súborov máte často tendenciu používať predvolené správanie príkazu „git add“, ktorým je pridanie všetkých súborov a adresárov do indexu.Mnohokrát pocítite potrebu zrušiť fázovanie určitých súborov alebo ich naposledy upraviť pred ich spáchaním.



Syntax: git reset


odstrániť súbory z indexu - bežné chyby git -Edureka

Zrušenie vytvárania súborov z oblasti Register vám dáva ďalšiu šancu na prepracovanie vašich údajov skôr, ako sa zaviažete k miestnemu úložisku.



Upravte poslednú potvrdenú správu

Príkaz: git commit --amend
Poslednú správu o potvrdení môžete upraviť bez vytvorenia novej. Ak chcete uviesť zoznam denníkov potvrdenia, nastavil som alias „hist“:
Príkaz: git config --global alias.hist 'log --pretty = formát: '% C (žltý)% h% Creset% reklama | % C (zelená)% s% Creset% C (červená)% d% Creset% C (modrá) [% an] '--graph --decorate --date = short'x


Neupravujte správu o odovzdaní, ktorá je už odoslaná do vzdialeného úložiska a zdieľaná s ostatnými, pretože by tak bola predchádzajúca história potvrdenia neplatná, a tým by mohla byť ovplyvnená akákoľvek práca na nej založená.

Zabudol som na nejaké zmeny v poslednom potvrdení

Povedzme, že ste zabudli vykonať nejaké úpravy a už ste sa zaviazali vytvoriť svoj snímok. Rovnako už nechcete vykonať ďalšie potvrdenie, aby ste zvýraznili svoju chybu.
Príkaz: git commit --amend


Zdôraznil som, ako bolo znovu vytvorené a zmenené ID sha-1 objektu nedávneho spáchania. Predstieral som, že som urobil jediný záväzok, ktorý spojil obe zmeny do jednej.

Zahodiť miestne zmeny

Tu je teda prípad, keď som upravil súbor „README“ a pripravil ho. Ďalej som ten istý súbor upravil druhýkrát, ale uvedomil som si, že druhú zmenu nechcem.

Teraz mi dovoľte nevrátiť celú zmenu manuálne, môžem jednoducho stiahnuť postupnú verziu súboru.
Syntax:
pokladňa git -–Miestne zmeny v súbore
pokladňa git -–Miestne zmeny vo všetkých súboroch v adresári & shy & shy

zodpovedný vs kuchár vs bábka

Príkaz: pokladňa git - README

Zahodil som teda moje posledné zmeny v súbore a prijal som fázovanú verziu súboru. V nasledujúcom potvrdení sa do miestneho úložiska dostane iba postupná verzia súboru.

Potvrdené osobné údaje do miestneho úložiska

Chcem odstrániť určité údaje z miestneho úložiska, ale ponechať súbory v pracovnom adresári.
Syntax:
git reset --zmiešaná HLAVA ~
git reset - zmiešaný

Príkaz: git reset --zmiešaná HLAVA ~ 1
HEAD ~ 1 označuje potvrdenie tesne pred nedávnym potvrdením, ktoré ukazuje aktuálna vetva HEAD.

Súbory v aktuálnej snímke sa odstránili z miestneho úložiska aj z pracovnej oblasti. Pridajte nasledujúce vzory do globálneho súboru .gitignore, aby ste ich vylúčili zo sledovania pomocou git.
vim ~ / .gitignore_global
# súbory s heslom #
* .pass
*. kľúč
* .passwd

Týmto sa odstráni záväzok, ktorý mal snímku súborov hesiel, a získate čistú pracovnú oblasť. Moje súbory sú stále prítomné v mojom pracovnom adresári, ale už sa nenachádzajú v miestnom úložisku, taktiež sa nebudú tlačiť na vzdialené úložisko.

Pozor: Ak ich stratíte, git ich nemôže za vás obnoviť, pretože o tom nevie.

Nahraďte posledný potvrdenie novým potvrdením

Syntax: git reset --soft [/ HEAD ~ n>]

Možnosť „–soft“ iba odstráni potvrdené súbory z miestneho úložiska, kým sú stále umiestnené v indexe, a po kontrole ich môžete znova zaviazať. je sha-1 snímky, ktorú chcete odstrániť z miestneho úložiska. kde n je počet potvrdení pred vykonaním potvrdenia HEAD

Velenie :git reset --soft HEAD ~ 1


Upravte súbory a znova ich upravte

Príkaz: git commit -m 'Pridanie index.html a style.css'
Vaša história záväzkov sa teraz ukazuje:

Dopustil nesprávnych údajov

Syntax:
git reset --hard HEAD ~ n–Resetujte projekt tak, aby sa „n“ zaviazal pred poslednou potvrdenou snímkou
git reset --hard–Resetujte projekt do danej snímky potvrdenia id

Príkaz: git reset --hard HEAD ~ 1


Posledné potvrdenie a poškodené súbory sa odstránia z miestneho úložiska, pracovnej oblasti a tiež z pracovného adresára.

Pozor: Je to nebezpečný príkaz, pretože nakoniec stratíte súbory v pracovnom adresári. Neodporúča sa na vzdialene zdieľanom úložisku.

Vráťte sa do môjho starého stavu projektu

Môžete prejsť do staršieho stavu svojho projektu v histórii času. Ak sa pokazíte v najnovšej verzii alebo budete potrebovať vylepšenia v staršom kóde, možno budete chcieť vytvoriť inú vetvu zo starej snímky projektu, aby neprekážala v súčasnej práci. Pozrime sa, ako:
a. Vypíšte históriu projektu a rozhodnite sa pre staršie ID potvrdenia, príkaz:choď hist
b. Vytvorte ďalšiu vetvu z ID potvrdenia:git checkout -b old-state e7aa9a5
c. Pokračujte v práci na kóde a neskôr zlúčte alebo rebázujte pomocou pobočky ‘master’.

Obnovte odstránenú miestnu pobočku

Stratenú prácu je možné regenerovať na referenčnej vetve. Povedzme, odstránil som vetvu „old_code“ bez zlúčenia s hlavnou vetvou a stratil prácu. A nie, ani ja som netlačil pobočku na vzdialené úložisko, čo potom? Nuž, sledujte git a zaznamenajte si do denníka všetky zmeny vykonané pri každej referencii, pozrime sa na moje:choď reflog

HEAD @ {2} je teda ukazovateľ, keď som prešiel do vetvy „old_code“, obnovme to:

Syntax:pokladňa git -b
Príkaz:git checkout -b old_code HEAD @ {2}

V čase svojho vzniku musíte byť vo vetve „old_code“ so svojou najnovšou prácou. Ukazovateľ „reflog“ na adrese HEAD @ {1} bol navyše posledným potvrdením vykonaným vo vetve „old_code“. Obnovenie tohto jedinečného stačí spustiť príkaz ako:git reset --hard HEAD @ {1}.Týmto sa obnovia aj upravené súbory v pracovnom adresári.

Ak by ste sa chceli dozvedieť podrobnejšie, ako tento príkaz funguje a ako môžete spravovať položky „reflog“, môžete si tiež prečítať môj predchádzajúci príspevok naobnovenie odstránenej vetvy z git reflog.

Vrátiť späť zmeny vykonané vo potvrdení

choďprejsť späťsa používa na zaznamenanie niektorých nových záväzkov na zvrátenie účinku niektorých starších záväzkov.
Syntax: git vrátiť sa
Z mojich denníkov záväzkov by som chcel vrátiť späť zmenu vykonanú vo zvýraznenom ID potvrdenia:

Príkaz: git vráti 827bc0d

Je lepšie, aby ste nenastavili „tvrdé“ zdieľané potvrdenia, ale namiesto toho ich „vrátili späť“, aby uchovali históriu, aby bolo pre všetkých jednoduchšie vystopovať protokoly histórie a zistiť, čo sa vrátilo, kým a prečo?

Môžete použiť rovnakú logiku odkazovania na potvrdenia týkajúce sa ukazovateľa HEAD namiesto zadania ID potvrdenia, ako v HEAD ~ 3 alebo HEAD ~ 4 atď.

Dal som svojej pobočke nesprávne meno

Názov miestnej pobočky môžete premenovať. Mnohokrát sa stane, že budete chcieť premenovať svoju pobočku na základe problému, na ktorom pracujete, bez toho, aby ste prešli migráciou všetkej svojej práce z jedného miesta na druhé. Môžete byť napríklad v tej istej alebo inej pobočke a stále môžete byť schopní premenovať požadovanú pobočku, ako je to zobrazené nižšie:
Syntax: vetva git -m
Príkaz: git branch -m old_code old_ # 4920

Ako by vás mohlo zaujímať, git sleduje toto premenovanie? Áno, týka sa to vašich položiek „reflogovať“, tu je moje:

Premenovanie pobočky nebude mať vplyv na jej pobočku vzdialeného sledovania. Uvidíme vo vzdialenej časti, ako nahradiť vetvu na vzdialenom úložisku

Pred presunutím do vzdialeného režimu znova usporiadajte protokoly histórie

Ako by som si prial, aby som urobil určité záväzky skôr ako iné a neurobil by som vôbec nejaké. Interaktívne znova usporiadajte a upravte staré záväzky, aby ste mohli kód efektívne opraviť alebo vylepšiť
Syntax: git rebase -i
Príkaz: git rebase -i fb0a90e–Štartovať rebasing záväzkov, ktoré boli urobené po Commit-id fb0a90e

Znova navštívte stránku git rebase dokumentácia, aby ste pochopili, ako sa odlišuje rebáza „–interaktívna alebo -i“ od bežnej rebázy.

Potvrdené nesúvisiace zmeny do jedného potvrdenia

V takom prípade musíte rozdeliť starý zakopaný príkaz na viac logických potvrdení.
Syntax: git rebase -i
Príkaz: git rebase -i fb0a90e
V editore rebase musíte zvoliť e7aa9a5 commit id a zmeniť ho na „edit“ namiesto „pick“.

nesúvisiace zmeny - bežné chyby git -Edureka

Teraz by ste sa mali nachádzať vo verzii projektu potvrdenia id-e7aa9a5. Najskôr resetujte históriu a oblasť vykonávania revízií na predchádzajúci príkaz príkazu:git reset HLAVA ~ 1
Po druhé, upravte + etapa + odovzdajte súbory jednotlivo
Príkazy:
git pridať kód && git commit -m 'Pridanie počiatočných kódov'
git pridať nový kód && git commit -m 'Pridanie nového kódu'

Po tretie, pokračujte v rebase a skončite.

Velenie :git rebase - pokračovať
Po štvrté, pozrite si históriu s ďalšími záväzkami.

Príkaz: choď hist

rozdelenie potvrdenia na viac pomocou rebase - bežné chyby git - Edureka

Zmeňte e-mail autora vo všetkých záväzkoch na všetkých pobočkách

Verziu a potvrdzovanie svojich projektových súborov v gite vykonávam už dlho, ale až doteraz ma nikdy neprekvapilo, že moje ID e-mailu bolo napadnuté v mojich protokoloch histórie potvrdenia, ktoré sú dokonca zverejnené na vzdialených úložiskách. To sa môže stať každému, keď pôvodne nastavujete konfigurácie v súbore „.gitconfig“. K môjmu úľavu môže git prepísať premenné prostredia, ktoré poskytujeme pri vytváraní objektu potvrdenia.

Najprv dostanem zoznam e-mailové ID rozhodnúť sa, ktoré chcem zmeniť:
Príkaz: git log --all --pretty = formát: '% an% d'–Toto vypíše meno autora (refname / branch-name)

Po druhé prebehnem každý záväzok na každej pobočke a znova napíš objekt potvrdenia s novým ID e-mailu
Príkaz:
git filter-vetva --env-filter '
if ['$ GIT_AUTHOR_NAME' = 'divya']
potom
GIT_AUTHOR_EMAIL = 'divya@github.com'
byť
„- - všetky

Stratené a nájdené súbory

Predpokladajme, že ste stratili určitý súbor a nepamätáte si jeho názov, ale spomenuli ste si na určité slová v súbore. V takom prípade môžete postupovať podľa týchto krokov -
Krok 1: Uveďte zoznam všetkých záväzkov, ktoré kedy obsahovali snímku súboru, s hľadaným vzorom
Velenie :git rev-list - všetko | xargs git grep -i 'timestamp'



Krok 2 : Vytvorte novú vetvu ‘lost-found’ z tohto zvýrazneného commit-id
Syntax: git checkout -b stratený-nájdený d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f

Zabudli ste, ktorá pobočka má moje commit-id

Občas, keď zistíte identifikáciu chyby v bugine, možno budete chcieť poznať všetky vetvy, ktoré majú na sebe tento commit, aby ste ich mohli všetky opraviť. Skontrolovať históriu každej pobočky nie je vo veľkom projekte s viacerými pobočkami veľmi praktické.

Zlé spáchanie vykonané v mojej aplikácii navigačnej budovy raz prelomilo kód, vtedy som použil Príkaz „git bisect“ na zistenie zlého ID potvrdenia nasledovanépríkaz:vetva git --obsahujevypísať pobočky so zlým spáchaním.

Takže teraz poznám všetky vetvy, ktoré majú stále zlé spáchanie, a mohol by som buď vrátiť alebo resetovať túto sadu zmien.

Odstrániť potvrdenie z histórie

Niekedy cítim potrebu jednoducho vymazať záväzok z histórie a nezanechať po ňom žiadnu stopu. Neodporúčal by som vám vyskúšať tento trik na zdieľanej pobočke, ale iba na miestnej pobočke.
Syntax: git rebase -i
Velenie :git rebase -i 93859d8
V editore rebase-> nahraďte „edit“ za „drop“ pre zvýraznené potvrdenie id: 69f4813

V niektorých prípadoch môže toto prepísanie viesť ku konfliktom. Musíte vyriešiť konflikty a pokračovať ďalej.

Výstraha : Toto je nebezpečný príkaz, pretože tým sa prepisuje história a môže dôjsť k strate údajov. Takáto vetva sa líši od vzdialeného náprotivku a bude ju treba pretlačiť- silaalebo--silu s prenájmommožnosť.

Do diaľkového ovládača bola odoslaná nesprávna vetva

Teraz je tu to, čo chcem urobiť - chcem odstrániť a vzdialená pobočka a tiež to prestať sledovať z mojej miestnej pobočky. “git tlačiť„Príkaz, ak sa používa s- vymazaťvoľba vymaže vzdialenú vetvu Takže takto dostanem miestnu kópiu klonovaného projektu -

git klon https://github.com/greets/myProj.git
cd myProj


Akonáhle je vzdialená vetva odstránená, ostatní v zdieľanom repo musia aktualizovať a aktualizovať svoje vzdialené referencie pomocou--prunmožnosť odstrániť chýbajúce odkazy na objekty:git fetch --prune -v pôvod

V tomto príspevku som spomenul niektoré bežné chyby alebo zmeny, ktoré vám git môže pomôcť opraviť. Každý kód je jedinečný a je vyvinutý svojim spôsobom, takže existujú aj rôzne spôsoby riešenia problému. Vždy ste sa mohli odvolať na úradníka dokumentácia git aby ste pochopili, ako rôzne príkazy git chránia váš zdrojový kód a ako ich čo najlepšie využiť.

Teraz, keď ste pochopili bežné chyby Gitu, pozrite sa na toto autor: Edureka, dôveryhodná online vzdelávacia spoločnosť so sieťou viac ako 250 000 spokojných študentov rozmiestnených po celom svete. Kurz certifikácie EdOkaka DevOps Certification Training pomáha študentom pochopiť, čo je DevOps, a získať odborné znalosti v rôznych procesoch a nástrojoch DevOps, ako sú Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack a GIT na automatizáciu viacerých krokov v SDLC.

Máte na nás otázku? Uveďte to prosím v sekcii komentárov k týmto „častým chybám Gitu“ a my sa vám ozveme