„Ați pierdut vreodată o ramură, al cărei cod sursă nu a fost încă fuzionat în ramura„ lansare ”sau ramura„ principală ”? Ce se întâmplă dacă doriți să regenerați o ramură ștearsă, deși activitatea sa a fost deja fuzionată cu ramura principală? ” . Ei bine, singura soluție la astfel de scenarii este Accesați Reflog .
Prin acest articol despre Git Reflog, vă voi ajutaînțelegeți scenariile în care munca dvs. pe o sucursală ar putea fi pierdută și cum să recuperați sucursala.De asemenea, acest articol va evidenția abordarea pe care ați putea să o luați pentru a preveni pierderea neintenționată a unei sucursale în timp ce lucrați într-un proiect mare.
Deci, haideți să începem cu acest articol.
Luați în considerare un scenariu, un maintainer trebuie să îmbine mai multe ramuri de caracteristici de la diferiți colaboratori și apoi să le șteargă în cele din urmă, dar sucursala este ștearsă accidental înainte ca lucrarea să poată fi îmbinată?
Ei bine, înainte de a trece la acest articol, permiteți-mi să vă spun că nu este posibil în Git. sunt sigure și acționează ca un post de verificare nu v-ar permite să faceți acest lucru. Deci, aici apare Git Reflog.
Ce este Git Reflog?
Comanda ‘reflog’ păstrează o pista de fiecare schimbare făcută în referințe (ramuri sau etichete) ale unui depozit și păstrează un istoric de jurnal al ramurilor și etichetelor care au fost create local sau au fost verificate. Jurnalele de referință, cum ar fi instantaneul de confirmare a momentului în care ramura a fost creată sau clonată, extrasă, redenumită sau orice validări efectuate pe ramură sunt menținute de și listate prin comanda „reflog”.
Notă: Sucursala va fi recuperabilă din directorul dvs. de lucru numai dacă ramura a existat vreodată în depozitul dvs. local, adică sucursala a fost creată local sau a fost extrasă dintr-un depozit la distanță în depozitul dvs. local pentru ca Git să stocheze istoricul de referință al acestuia.
Această comandă trebuie executată în depozitul care a avut ramura pierdută. Dacă luați în consideraresituația depozitului la distanță, atunci trebuie să executați comanda reflog pe computerul dezvoltatorului care a avut sucursala.
cum se generează un șir aleatoriu în java
comanda: du-te reflog
Acum că știți, ce este Git Reflog, permiteți-neîncercați să ștergeți atât o ramură îmbinată, cât și o ramură necombinată și să vedeți cum gestionează Git asta?
Pasul 1: enumerați ramurile care sunt îmbinate în master
Mai întâi, verificați în „ maestru 'Branch dacă vă aflați într-o altă ramură folosind comanda:
$ git checkout master
Ieșire
Acum, pentru a obține o listă de ramuri combinate, menționați următoarea comandă:
$ git branch - fuzionat
Ieșire:
Pasul 1.1: Ștergeți ramura combinată:
$ git branch -d numărul # 902
Ieșire:
Sucursala „problema # 902” a fost ștearsă cu succes, deoarece este deja îmbinată cu ramura „master”.
Pasul 2: Acum, să listăm ramurile care nu sunt fuzionate în master.
$ git branch --no-fuzionată
Ieșire
Pasul 2.2: În cele din urmă, permiteți-ne să ștergem o ramură necombinată cu următoarea comandă:
$ git branch -d prepod
Dacă încercați să ștergeți una dintre ramuri cu lucrări nefinalizate, spuneți ramură „preprod”, git afișează un mesaj de avertizare.
Ieșire
Acum, înainte să vă spun cum puteți recupera datele din acest articol pe Git Reflog, permiteți-mi să vă spun ce se întâmplă exact când o sucursală este ștearsă și în ce circumstanțe poate fi recuperată sucursala.
Cum și când o sucursală este ștearsă?
După cum știm că Git este un Sistem de control al versiunii distribuite (DVCS), fiecare mașină cu clona sau o copie a depozitului acționează ca ambele nodul și a hub . Acestimplică faptul că fiecare mașină va avea propria copie a întregului cod și istoric al depozitului.Inutil să spun că vei fi partajare munca ta cu alții și publicarea la fel.
Prin urmare, în astfel de scenarii, ar putea exista 3 cazuri când o sucursală este ștearsă într-un scenariu din lumea reală, cu mulți colaboratori care lucrează la un proiect mare. Următoarele ar putea fi cazurile:
Cazul 1 - Un dezvoltator poate fuziona sau șterge ramura
Luați în considerare un scenariu în care un dezvoltator fuzionează local ramura caracteristică cu ramura principală și apoi șterge ramura caracteristică utilizând „ ramură git 'Cu comanda „- d ”Semnalizat așa cum se vede în capturile de ecran anterioare.
Comanda: „Git branch -d branch_name”
S-ar putea întâmpla, de asemenea, ca dezvoltatorul să decidă eliminarea modificărilor de pe ramură și să decidă să șteargă ramura fără a o combina cu orice altă ramură folosind următoarea comandă:
care sunt cazuri în java
Comanda: „Git branch -D branch_name”
Cu comanda de mai sus, dezvoltatorul esteștergeți cu forță ramura care anulează avertismentul git
$ git branch -D preprod
Ieșire
Notă : Ramura „preprod” nu va mai fi listată atunci când executați comanda „git branch”. Deci, damunca noastră salvată pe această ramură se va pierde.
Cazul 2 - Un dezvoltator șterge o ramură dintr-un depozit partajat
Luați în considerare un scenariu în care un dezvoltator cu acces la citire / scriere încearcă să șteargă cu succes ramificația la distanțăfolosind comanda „git push” cu steagul „– șterge”.
$ git push origine - ștergeți quickfix
Ieșire
În afară de aceasta, ar putea exista și un caz în care un utilizator neautorizat sau rău intenționat forțează o apăsare să șteargă ramura la distanță.În acest caz, administratorul va putea recupera ramura „quickfix” ștearsă numai dacă dezvoltatorulverificasem anterior această filială. În acest scenariu, depozitul său local va avea în continuare jurnale de referință ale acestuia.
Dacă întreținătorul nu poate recupera sucursala, atunci proprietarul sucursalei care a șters-o trebuie să se recupereze din reflogurile sale locale.
Cazul 3 - Un script cârlig cu super privilegii șterge ramura
Acesta ar putea fi un scenariu rar, dar posibil, în care un script de cârlig este declanșat la un anumit eveniment de operație git și forța șterge ramurile care nu sunt încă îmbinate. Poticonsiderați că una dintre comenzile menționate mai sus este scriptată într-un script cârlig cu privilegii sudo.
Acum, că știi ce se întâmplă, când ștergi sucursala, lasă-ne să trecem mai departe cu acest articol pe Git Reflog și să vedem cum să recuperezi o sucursală pierdută.
Recuperați o sucursală ștearsă utilizând Git Reflog
Pasul 1 : Jurnalele istorice ale tuturor referințelor
Obțineți o listă cu toate istoricele înregistrate la nivel local pentru toate referințele („master”, „uat” și „prepod”) din acest depozit.
du-te reflog
Pasul 2 : Identificați ștampila de istorie
După cum puteți consulta din instantaneul de mai sus, ID de validare evidențiat: e2225bb împreună cu indexul indicatorului HEAD: 4 este cel când revânzare Ramura a fost creată din pointerul HEAD curent care indică cea mai recentă lucrare.
Pasul 3 : Recupera
Pentru a recupera înapoi 'Revânzare ‘Ramură folosește comanda„Git checkout” trecând referința pointerului HEAD cu ID-ul indexului - 4.Aceasta este referința indicatorului atunci când ramura „preprod” a fost creată ID-ul de validare lung evidențiat în captura de ecran de ieșire.
git checkout -b preprod HEAD @ {4}Ieșire
Și voila! ‘ revânzare „Ramura este recuperată înapoi cu tot codul sursă.
NOTĂ : Lasă-mă bdescărcați comanda „git checkout” folosită mai sus și vă ajută să înțelegeți mai bine:
Comanda ‘git checkout’ este o comandă supraîncărcată (la fel ca orice funcție Java supraîncărcată). Aceasta este partea în care ramura reală este recuperată.
Această comandă unică verifică mai întâi marca de timp istorică anterioară indicată de Indicatorul HEAD @ {4} și apoi creează o ramură cu numele „preprod” folosind opțiunea „-b”, precum și comută directorul dvs. de lucru la ramura nou creată.
Aceasta implică faptul că ramura comutată va fi de la „master” la „preprod”, așa cum este indicat în ecranul de ieșire.Acum puteți să-l combinați cu ramul „master” sau „release” conform modelului dvs. de ramificare.
Acum, că știți cum să restaurați o ramură, permiteți-mi să vă spun ce lucru este restaurat atunci când o ramură ștearsă este recuperată.
Ce lucru se restabilește atunci când ramura ștearsă este recuperată?
Fișierele care au fost stocate și salvate în lista indexului de stocare vor fi recuperate înapoi. Orice fișier nerecuperat se va pierde. De asemenea euEste o idee bună să vă puneți în scenă și să vă angajați întotdeauna munca sau să le ascundeți.
Pentru a prelua referințele jurnalului unei anumite ramuri sau etichete, executați comanda - „git reflog”.
Exemplu: Pentru a verifica referințele jurnalului ramurii ‘uat’, folosiți singură comanda - „git reflog uat”.
Sub-comenzi Git Reflog
du-te reflog
Comandă pentru a deschide pagina manuală
$ git reflog --help
Ieșire
du-te reflog spectacol
Afișează jurnalele referinței furnizate în linia de comandă.
git reflog show master @ {0}du-te reflog expira
Această comandă este utilizată pentru a tunde intrările reflog mai vechi.
git reflog expiră
du-te reflog șterge
Această comandă șterge intrări individuale din istoricul reflog.
git reflog delete
du-te reflog există
cum se implementează metoda abstractă în java
Această comandă verifică dacă un ref (ramură sau etichetă) are un reflog - înregistrări istoric jurnal.
git reflog există
În afară de comenzile menționate mai sus, comanda „Git Reflog” are diverse subcomenzi și diferite opțiuni în funcție de subcomandele menționate mai sus. Pentru lecturi suplimentare, rulați „ git reflog –help ”Din fereastra terminalului.
Cu aceasta, ajungem la sfârșitul acestui articol despre Git Reflog.Intenția DevOps este de a crea software de calitate mai bună mai rapid și cu mai multă fiabilitate, invitând în același timp o comunicare și o colaborare mai mari între echipe. Dacă sunteți intrigați de acest articol, c uită-te la 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 diferite 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ă îl menționați în secțiunea de comentarii a articolului „Git Reflog” și vă vom răspunde cât mai curând posibil.