Git Reflog - Hur man återställer en borttagen gren som inte slogs samman



Den här artikeln om Git Reflog är en omfattande guide för hur du återställer de raderade grenade i Git med hjälp av Git Reflog.

'Har du någonsin tappat en filial vars källkod ännu inte slogs samman i' release '-grenen eller' main '-grenen? Vad händer om du vill regenerera en borttagen gren även om dess arbete redan har slagits samman till huvudgrenen? ” . Tja, den enda lösningen på sådana scenarier är Gå omloggning .

Genom den här artikeln om Git Reflog hjälper jag digförstå scenarierna där ditt arbete på en filial kan gå förlorat och hur du återställer filialen.Den här artikeln kommer också att belysa det tillvägagångssätt du kan ta för att förhindra oavsiktlig förlust av en filial när du arbetar i ett stort projekt.





    1. Vad är Git Reflog?
    2. Hur och när en filial raderas?
    3. Återställ en borttagen gren
    4. Vilket arbete återställs när den borttagna filialen återställs?
    5. Git Reflog Underkommandon

Så låt oss komma igång med den här artikeln.



Tänk på ett scenario, en mmåste aintainer slå samman många funktionsgrenar från olika medarbetare och sedan ta bort dem så småningom men filialen raderas av misstag innan arbetet kunde slås samman?

Innan jag går vidare med den här artikeln, låt mig berätta att det inte är möjligt i Git. är säkra och fungerar som ett checkpost inte tillåter dig att göra det. Så det här där Git Reflog kommer in i bilden.

Vad är Git Reflog?

De”Reflog” -kommandot håller en spår av varje ändring som görs i referenserna (grenar eller taggar) i ett arkiv och håller en logghistorik över de grenar och taggar som antingen skapades lokalt eller checkades ut. Referensloggar, till exempel en snapshot-bild av när filialen skapades eller klonades, utcheckades, döptes om eller eventuella åtaganden som gjordes på filialen underhålls av och listas av kommandot 'reflog'.



Notera: Filialen kan bara återställas från din arbetskatalog om filialen någonsin funnits i ditt lokala arkiv, dvs. filialen skapades antingen lokalt eller checkades ut från ett fjärrlager i ditt lokala förråd för att Git ska lagra sina referenshistorikloggar.

Detta kommando måste köras i förvaret som hade den förlorade grenen. Om du funderar påfjärrförvarssituation måste du köra reflog-kommandot på utvecklarens maskin som hade filialen.

kommando: gå omloggning

Nu när du vet, vad är Git Reflog, låt ossförsök att ta bort både en sammanslagen och en icke-sammanslagen gren och se hur Git hanterar det?

Steg 1: Lista de grenar som slås samman till master

Kolla först in i bemästra Gren om du befinner dig på någon annan gren med kommandot:

$ git kassamästare

Produktion

Git Checkout Master - Git Reflog - Edureka

Nu, för att få en lista över sammanslagna grenar, nämna följande kommando:

vad är skillnaden mellan hashmap och hashtable
$ git gren - sammanslagna

Produktion:

Steg 1.1: Ta sedan bort den sammanslagna grenen:

$ git filial -d nummer # 902

Produktion:

Filialen 'nummer # 902' raderades framgångsrikt eftersom det redan slogs samman till 'master' -grenen.

Steg 2: Låt oss nu lista de grenar som inte slås samman till master.

$ git-filial - ingen sammanslagning

Produktion

Steg 2.2: Slutligen, låt oss ta bort en icke sammanslagen gren med följande kommando:

$ git gren -d prepod

Om du försöker ta bort en av grenarna med oavslutat arbete, säg 'preprod' -gren, visar git ett varningsmeddelande.

Produktion

Nu, innan jag berättar för dig hur du kan återställa data den här artikeln på Git Reflog, låt mig berätta vad som exakt händer när en filial raderas och under vilka omständigheter kan filialen återställas.

Hur och när en filial raderas?

Som vi vet att Git är en Distribuerat versionskontrollsystem (DVCS), varje maskin med klonen eller en kopia av förvaret fungerar som båda nod och a nav . Dettainnebär att varje maskin har sin egen kopia av hela förvarskoden och historiken.Det behöver inte sägas att du kommer att bli det delning ditt arbete med andra och publicering det samma.

c ++ sorteringsalgoritm

Därför kan det i sådana scenarier vara 3 fall när en filial raderas i ett verkligt scenario med många bidragsgivare som arbetar med ett stort projekt. Följande kan vara fallen:

Fall 1 - En utvecklare kan antingen slå samman eller ta bort filialen

Tänk på ett scenario där en utvecklare slår samman funktionsgrenen i huvudgrenen lokalt och sedan raderar funktionsgrenen med hjälp av ' git gren Kommandot med “- d ”-Flagga som ses i tidigare skärmdumpar.

Kommando: 'Git branch -d branch_name'

Det kan också hända att utvecklaren bestämmer sig för att kasta bort ändringarna på filialen och beslutar att ta bort filialen utan att slå samman den med någon annan gren med följande kommando:

Kommando: 'Git branch -D branch_name'

Med ovanstående kommando är utvecklarenradera kraftigt grenen som åsidosätter gitvarningen

$ git gren -D preprod

Produktion

Notera : 'Preprod' gren kommer inte längre att listas när du kör kommandot 'git branch'. Så, yvårt arbete som sparats på denna gren kommer att gå förlorat.

Fall 2 - En utvecklare tar bort en filial i ett delat arkiv

Tänk på ett scenario där en utvecklare med läs- / skrivåtkomst försöker radera fjärrgrenen med kraftmed kommandot 'git push' med '–delete' -flaggan.

$ git push-ursprung - radera snabbkorrigering

Produktion

Bortsett från detta kan det också finnas ett fall där en obehörig eller skadlig användare tvingar ett tryck för att ta bort fjärrgrenen.I sådana fall kommer underhållaren att kunna återställa den borttagna 'quickfix'-grenen endast om utvecklarenhade tidigare checkat ut den här filialen. I det här scenariot kommer dess lokala förvar fortfarande att ha referensloggar.

Om underhållaren inte kan återställa filialen måste ägaren till filialen som raderade den återhämta sig från sina lokala återloggningar.

Fall 3 - Ett krokskript med superprivilegier raderar filialen

Detta kan vara en sällsynt men ett möjligt scenario som ett krokskript utlöses vid en viss gitoperationshändelse och kraft raderar de grenar som inte är sammanslagna ännu. Du kanöverväga att en av de ovan nämnda kommandona är skriptade i ett krokskript med sudo-privilegier.

Nu när du vet vad som händer, när vi tar bort filialen, låt oss gå vidare med den här artikeln på Git Reflog och se hur du återställer en förlorad gren.

Återställ en borttagen gren med Git Reflog

Steg 1 : Historikloggar över alla referenser

Få en lista över alla lokala inspelade historikloggar för alla referenser ('master', 'uat' och 'prepod') i detta arkiv.

gå omloggning

Steg 2 : Identifiera historikstämpeln

Som du kan hänvisa till från ovanstående ögonblicksbild är Markerat engagemangs-id: e2225bb tillsammans med HEAD-pekareindex: 4 är den när ” återförsäljning Gren skapades från den nuvarande HEAD-pekaren som pekade på ditt senaste arbete.

Steg 3 : Ta igen sig

För att återställa 'Återförsäljning 'Filial använder kommandot”Git checkout” passerar HEAD-pekarens referens med index-id - 4.Detta är pekarehänvisningen när 'preprod' -grenen skapades långt engagemang-ID markerat i utskärmen.

git checkout -b preprod HEAD @ {4}

Produktion

vad gör en iOS-utvecklare

Och voila! ” återförsäljning 'Filial återställs med all din källkod.

NOTERA : Låt mig breakup kommandot ”git checkout” som används ovan och hjälper dig att förstå bättre:

”Git checkout” -kommandot är ett överbelastat kommando (Precis som alla Java-överbelastade funktioner). Detta är den del där den faktiska filialen återställs.

Detta enda kommando kontrollerar först till den tidigare historiska tidsstämpeln som pekas av Peka på HEAD @ {4} och skapar sedan en gren med namnet 'preprod' med alternativet '-b' samt växlar din arbetskatalog till den nyskapade grenen.

Detta innebär att den växlade grenen kommer att vara från 'master' till 'preprod' som anges i utskärmen.Du kan nu slå samman den med 'master' eller 'release' -grenen enligt din förgreningsmodell.

Nu när du vet hur du återställer en gren, låt mig berätta vad arbete återställs när en borttagen gren återställs.

Vilket arbete återställs när den borttagna filialen återställs?

Filerna som lagrats och sparats i listan över stashindex återställs. Alla ospårade filer kommer att gå förlorade. Även jagt är en bra idé att alltid iscensätta och begå ditt arbete eller stash dem.

För att hämta loggreferenser för en viss gren eller tagg kör du kommandot - “git reflog”.

Exempel: För att kontrollera loggreferenserna för 'uat' gren ensam använder du kommandot - 'git reflog uat'.

Git Reflog Underkommandon

gå omloggning

Kommando för att öppna den manuella sidan

$ git reflog - hjälp

Produktion

gå omloggning show

Visar loggarna för referensen i kommandoraden.

git reflog show master @ {0}

gå omloggning upphöra

Detta kommando används för att beskära de äldre reflogposterna.

git reflog går ut

gå omloggning radera

Detta kommando raderar enskilda poster från refloghistoriken.

git reflog radera

gå omloggning existerar

Detta kommando kontrollerar om en ref (filial eller tagg) har en reflog - logghistorikposter.

git reflog finns

Förutom de ovan nämnda kommandona tar kommandot “Git Reflog” olika underkommandon och olika alternativ beroende på de underkommandon som nämns ovan. För vidare läsning kör “ git reflog –hjälp ”Från terminalfönstret.

Med detta kommer vi till ett slut på den här artikeln om Git Reflog.Avsikten med DevOps är att skapa programvara av bättre kvalitet snabbare och med mer tillförlitlighet samtidigt som man bjuder in större kommunikation och samarbete mellan team. Om du är intresserad av den här artikeln, c heck ut av Edureka, ett pålitligt online-lärande företag med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka DevOps Certification Training-kursen hjälper eleverna att förstå vad som är DevOps och få expertis inom olika DevOps-processer och verktyg som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack och GIT för att automatisera flera steg i SDLC.

Har du en fråga till oss? Vänligen nämna det i kommentarsektionen i ”Git Reflog” -artikel så återkommer vi till dig ASAP.