Cu boom-ul tehnologie, devine inevitabil ca orice persoană IT să lucreze simultan pe mai multe date, iar datele dvs. evoluează mereu în timp. De asemenea, este esențial să urmăriți fiecare modificare a datelor și să fiți pregătiți să anulați sau să reveniți la orice modificare nedorită atunci când este necesar.
Trebuie să mărturisesc, versionarea datelor mele în Git îmi permite să fiu mai experimental în dezvoltarea proiectului meu. Dacă mă încurc, știu că git are întotdeauna o modalitate de a anula și / sau a reveni la acea versiune a proiectului meu la felul în care era înainte de a mă înșela. Fiecare layer-ul este conceput pentru a permite modificărilor de date să fie revizuite și modificate și / sau corectate înainte de a muta datele în etapa următoare. Deci, următoarele sunt greșelile care sunt acoperite în acest blog:
- Anulați etapizarea fișierelor / directoarelor din Index
- Editați ultimul mesaj angajat
- Am uitat câteva modificări în ultima comitere
- Renunțați la modificările locale
- A trimis date cu caracter personal către depozitul local
- A înlocuit ultimul commit cu un commit nou
- A comis date greșite
- Reveniți la vechea mea stare de proiect
- Recuperați o sucursală locală ștearsă
- Anulați modificările efectuate într-un commit
- Am dat un nume greșit filialei mele
- Doriți să rearanjați jurnalele istorice înainte de a trece la telecomandă
- A făcut modificări fără legătură într-un singur commit
- Schimbați autorul-e-mail în toate confirmările de pe toate ramurile
- Fișiere pierdute și găsite
- Am uitat care ramură are ID-ul meu de comitere
- Ștergeți un commit din istoric
- A împins o ramură greșită la telecomandă
Anulați etapizarea fișierelor / directoarelor din Index
În timp ce adăugați și / sau modificați fișiere, adesea aveți tendința de a utiliza comportamentul implicit al comenzii „git add”, care este de a adăuga toate fișierele și directoarele la Index.De multe ori simți nevoia să dezinstalezi anumite fișiere sau să le modifici ultima dată înainte de a le comite.
Sintaxă: git reset
Anularea stocării fișierelor din zona Index vă oferă o altă șansă de a relucra datele dvs. înainte de a vă angaja într-o repo locală.
Editați ultimul mesaj angajat
Comanda: git commit --amend
Puteți edita cel mai recent mesaj de confirmare fără a crea unul nou. Pentru a lista jurnalele de comitere, am setat un alias „hist”:
Comanda: git config --global alias.hist 'log --pretty = format: '% C (galben)% h% Creset% ad | % C (verde)% s% Creset% C (roșu)% d% Creset% C (albastru) [% an] '--graph --decorate --date = short'x
Nu modificați mesajul de confirmare care este deja împins într-un depozit la distanță și partajat cu alții, deoarece acest lucru ar face ca istoricul de confirmare anterior să fie invalid și, prin urmare, orice lucru bazat pe acesta poate fi afectat.
Am uitat câteva modificări în ultima comitere
Să presupunem că ați uitat să faceți unele modificări și că v-ați comis deja instantaneul, de asemenea, nu doriți să faceți o altă comisie pentru a vă evidenția greșeala.
Comanda: git commit --amend
Am evidențiat modul în care id-ul sha-1 al obiectului de comitere recent a fost recreat și modificat. M-am prefăcut că am făcut o singură comisie amestecând ambele modificări într-una singură.
Renunțați la modificările locale
Deci, iată un caz în care am modificat fișierul „README” și l-am pus în scenă. Apoi, am modificat același fișier a doua oară, dar mi-am dat seama că nu doresc a doua schimbare.
Acum, permiteți-mi să nu anulez întreaga modificare manual, pur și simplu pot extrage versiunea etapizată a fișierului.
Sintaxă:
git checkout -–Modificări locale într-un fișier
git checkout -–Modificări locale în toate fișierele din director & timid & timid
Comanda: git checkout - README
Așadar, am renunțat la ultimele modificări ale fișierului și am acceptat versiunea etapizată a fișierului. În următorul commit, doar versiunea etapizată a fișierului intră în depozitul local.
A trimis date cu caracter personal către depozitul local
Vreau să elimin anumite date din depozitul local, dar să păstrez fișierele în directorul de lucru.
Sintaxă:
git reset - HEAD mixt ~
git reset --amixed
Comanda: git reset --mixed HEAD ~ 1
HEAD ~ 1 indică un commit chiar înainte de commitul recent indicat de ramura curentă HEAD.
Fișierele din instantaneul curent au fost eliminate atât din depozitul local, cât și din zona intermediară. Adăugați următoarele modele în fișierul global .gitignore pentru a le exclude de la urmărirea de către git.
vim ~ / .gitignore_global
# fișiere cu parole #
*.trece
*.cheie
* .passwd
Cu aceasta, comitetul care a avut instantaneul fișierelor cu parolă este eliminat și veți obține o zonă curată de stocare. Fișierele mele sunt încă prezente în directorul meu de lucru, dar nu mai sunt prezente în depozitul local, de asemenea, nu vor fi împinse pe un depozit la distanță.
Prudență: Dacă le pierzi, git nu le poate recupera pentru că nu știe despre asta.
Înlocuiți ultimul commit cu un commit nou
Sintaxă: git reset --soft [/ HEAD ~ n>]
Opțiunea „–soft” elimină doar fișierele angajate din depozitul local în timp ce acestea sunt încă aranjate în index și le puteți reconfirma după o examinare. este sha-1 al instantaneului pe care doriți să îl eliminați din repo-ul local. unde n este numărul de confirmări înainte de confirmarea HEAD
Comanda :git reset --soft HEAD ~ 1
Modificați fișierele și puneți-le din nou în scenă
Comanda: git commit -m 'Adăugarea index.html și style.css'
Istoricul dvs. de comitere se dovedește acum a fi:
gestionarea sesiunii în aplicația web java
A comis date greșite
Sintaxă:
git reset - hard HEAD ~ n–Resetați proiectul pentru a „n” comite înainte de cel mai recent instantaneu angajat
git reset --hard–Resetați proiectul la instantaneul dat de comitere dat
Comanda: git reset - hard HEAD ~ 1
Ultimele comiteri și fișierele corupte sunt eliminate din depozitul local, din zona de stocare, precum și din directorul de lucru.
Prudență: Este o comandă periculoasă, deoarece pierzi fișiere în directorul de lucru. Nu este recomandat într-un depozit partajat de la distanță.
Reveniți la vechea mea stare de proiect
Puteți ajunge la o stare mai veche a proiectului dvs. în istoria timpului. Dacă vă deranjați în cea mai recentă versiune sau aveți nevoie de îmbunătățiri în codul mai vechi, vă recomandăm să creați o altă ramură din acel instantaneu de proiect vechi pentru a nu împiedica munca dvs. curentă. Să vedem cum:
A. Enumerați istoricul proiectului și alegeți mai vechiul cod de comandă, comanda:du-te hist b. Creați o altă ramură din ID-ul de validare:
git checkout -b vechi-stare e7aa9a5
c. Continuați să lucrați la cod și apoi să fuzionați / rebase cu ramura „master”.
Recuperați o sucursală locală ștearsă
Este posibil să regenerați opera pierdută pe o ramură de referință. Spuneți, am șters ramura „cod_vechi” fără să fuzionez cu ramura principală și am pierdut lucrarea. Și nu, nici eu nu am împins ramura către un depozit la distanță, ce atunci? Ei bine, git tracks și păstrează o intrare în jurnal cu toate modificările făcute la fiecare referință, să o vedem pe a mea:du-te reflog
Deci, HEAD @ {2} este indicatorul când m-am mutat în ramura „cod_vechi”, să recuperăm:
Sintaxă:git checkout -b
Comanda:git checkout -b old_code HEAD @ {2}
Trebuie să vă aflați acum în ramura „cod_vechi” cu cea mai recentă lucrare la momentul creării sale. În plus, indicatorul „reflog” de la HEAD @ {1} a fost recenta confirmare făcută în ramura „cod_vechi”. Pentru a restabili această caracteristică unică commit doar executați comanda ca:git reset - HEAD hard @ {1}.Aceasta restabilește și fișierele modificate din directorul de lucru.
Dacă doriți să aflați în detaliu cum funcționează această comandă și cum puteți gestiona intrările „reflog”, puteți citi și postarea mea anterioară perecuperarea ramurii șterse din git reflog.
Anulați modificările efectuate într-un commit
mergerevenieste folosit pentru a înregistra unele confirmări noi pentru a inversa efectul unor confirmări anterioare.
Sintaxă: git revine
Din jurnalele mele de comitere, aș dori să inversez modificările efectuate în ID-ul de comitere evidențiat:
Comanda: git revert 827bc0d
Este mai bine să nu resetați '- dur' comitetele partajate, ci 'să le reveniți' pentru a păstra istoricul, astfel încât să devină mai ușor pentru toți să urmărească jurnalele istorice pentru a afla ce a fost revenit, de către cine și de ce?
Puteți utiliza aceeași logică de referire a validărilor referitoare la indicatorul HEAD în loc să dați ID-ul de validare, ca în HEAD ~ 3 sau HEAD ~ 4 și așa mai departe.
Am dat un nume greșit filialei mele
Puteți redenumi un nume de sucursală locală. Se întâmplă de multe ori că este posibil să doriți să vă redenumiți sucursala pe baza problemei la care lucrați, fără a trece prin durerea de a vă migra toată munca dintr-o locație în alta. De exemplu, puteți fi fie pe aceeași ramură, fie pe o ramură diferită și totuși puteți redenumi ramura dorită așa cum se arată mai jos:
Sintaxă: git branch -m
Comanda: git branch -m old_code old_ # 4920
Așa cum vă puteți întreba, git păstrează o urmă a acestei redenumiri? Da, se referă la intrările dvs. „reflog”, aici este a mea:
Redenumirea unei ramuri nu va afecta ramura sa de urmărire la distanță. Vom vedea în secțiunea la distanță cum să înlocuiți o ramură din depozitul la distanță
Reorganizați jurnalele istorice înainte de a trece la telecomandă
Cum aș dori să fi făcut anumite comitere mai devreme decât altele și nu aș fi făcut deloc unele comitere. Reorganizați interactiv și editați vechile comitere pentru a remedia eficient sau a îmbunătăți codul
Sintaxă: git rebase -i
Comanda: git rebase -i fb0a90e–Începeți să refaceți validările care au fost făcute după commit-id fb0a90e
Re-vizitați git rebase documentație pentru a înțelege în ce mod diferențiază un rebase „–interactiv sau -i” de un rebase obișnuit.
A făcut modificări fără legătură într-un singur commit
În acest caz, trebuie să împărțiți un vechi commit îngropat în mai multe commit logice.
Sintaxă: git rebase -i
Comanda: git rebase -i fb0a90e
În editorul rebase, trebuie să alegeți e7aa9a5 commit id și să îl schimbați în „edit” în loc de „pick”.
Acum veți fi în versiunea proiectului de commit id-e7aa9a5. Mai întâi, resetați istoricul de comitere și zona de etapizare la comanda de comitere anterioară:git reset HEAD ~ 1
În al doilea rând, editați + stage + comite fișierele individual
Comenzi:
git add code && git commit -m 'Adăugarea codurilor inițiale'
git add newcode && git commit -m 'Adăugarea unui cod nou'
În al treilea rând, continuați refacerea și terminați.
Comanda :git rebase --continue
În al patrulea rând, vizualizați istoricul cu confirmări suplimentare.
Comanda: du-te hist
Schimbați autorul-e-mail în toate confirmările de pe toate ramurile
Versionez și comit fișierele mele de proiect în git de mult timp, dar până acum nu mi-a părut niciodată faptul că id-ul meu de e-mail a fost compromis în jurnalele istoricului de comitere, care sunt chiar publicate în depozite la distanță. Ei bine, acest lucru se poate întâmpla oricui atunci când configurați inițial configurațiile în fișierul „.gitconfig”. rescrie variabilele de mediu pe care le oferim atunci când creăm un obiect commit.
Mai întâi primesc lista ID-uri de e-mail să decid cele pe care vreau să le schimb:
Comanda: git log --all --pretty = format: '% an% d'–Această imprimă numele autorului (refname / branch-name)
În al doilea rând, alerg fiecare angajare pe fiecare ramură și rescrieți obiectul commit cu noul ID de e-mail
Comanda:
git filter-branch --env-filter '
dacă ['$ GIT_AUTHOR_NAME' = 'divya']
apoi
GIT_AUTHOR_EMAIL = 'divya@github.com'
fi
' -- --toate
Fișiere pierdute și găsite
Să presupunem că ați pierdut un anumit fișier și nu vă amintiți numele acestuia, dar ați putea aminti anumite cuvinte din fișier. În acest caz, puteți urma acești pași-
Pasul 1: Enumerați toate validările care au conținut vreodată instantaneul fișierului cu modelul căutat
Comanda :git rev-list --all | xargs git grep -i 'timestamp'
Pasul 2 : Creați o ramură nouă „pierdut-găsit” din acest commit-id evidențiat
Sintaxă: git checkout -b pierdut-găsit d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Am uitat care ramură are ID-ul meu de comitere
Uneori, după ce ați detectat un ID de comitere buggy, este posibil să doriți să cunoașteți toate ramurile care au acest commit, astfel încât să le puteți remedia pe toate. Verificarea istoricului fiecărei sucursale nu este foarte practic într-un proiect cu mai multe ramuri.
O comitere greșită făcută în aplicația mea de construcție a navigației a rupt odată codul, atunci am folosit Comanda ‘git bisect’ pentru a detecta ID-ul de comitere care a fost rău urmat decomanda:git branch - conținepentru a enumera ramurile cu comiterea aceea rea.
Așadar, acum știu toate ramurile care încă au comiterea greșită, aș putea fie să revin, fie să resetați acest set de modificări.
Ștergeți un commit din istoric
Uneori simt nevoia să șterg o comitere din istorie și să nu las nici o urmă a acesteia. Nu v-aș recomanda să încercați această cascadorie pe o sucursală comună, ci doar pe sucursala dvs. locală.
Sintaxă: git rebase -i
Comanda :git rebase -i 93859d8
În editorul rebase-> înlocuiți „edit” cu „drop” pentru ID-ul de validare evidențiat: 69f4813
În unele cazuri, această rescriere poate duce la conflicte. Trebuie să rezolvați conflictele, apoi continuați mai departe.
Avertizare : Aceasta este o comandă periculoasă, deoarece aceasta rescrie istoricul și poate pierde date. O astfel de ramură diferă de omologul său la distanță și va trebui să fie împinsă cu--fortasau--forța-cu-leasingopțiune.
A împins o ramură greșită la telecomandă
Acum, iată ce vreau să fac - vreau să șterg un ramură îndepărtată și, de asemenea, nu mai urmăriți-l de la filiala mea locală. ”git push‘Comanda când este utilizată cu--ștergeopțiunea șterge ramura la distanță Deci, așa obțin copia locală a proiectului clonat -
git clone https://github.com/greets/myProj.git
cd myProj
Odată ce ramura la distanță este ștearsă, alte persoane din repo-ul partajat trebuie să reîmprospăteze și să-și actualizeze referințele la distanță cu--prună uscatăopțiunea de a șterge referințele de obiect lipsă:git fetch --prune -v origine
În această postare, am menționat câteva dintre greșelile sau modificările obișnuite pe care git vă poate ajuta să le remediați. Fiecare cod este unic și dezvoltat în felul său, deci există și diferite moduri de abordare și rezolvare a unei probleme. Te-ai putea referi întotdeauna la oficial documentație git pentru a înțelege cum diverse comenzi git vă protejează codul sursă și cum să utilizați comenzile în cel mai bun mod posibil.
Acum, că ați înțeles greșelile comune Git, verificați acest lucru de Edureka, o companie de învățare online de încredere, cu o rețea de peste 250.000 de elevi mulțumiți răspândiți pe tot globul. Cursul Edureka DevOps Certification Training îi ajută pe cursanți să înțeleagă ce este DevOps și să câștige expertiză în diverse procese și instrumente DevOps precum Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack și GIT pentru automatizarea mai multor pași în SDLC.
Ai o întrebare pentru noi? Vă rugăm să o menționați în secțiunea de comentarii a acestei „greșeli comune Git” și vă vom răspunde