“Har du nogensinde mistet en filial, hvis kildekode endnu ikke var flettet i 'release' -grenen eller 'main' -grenen? Hvad hvis du vil regenerere en slettet gren, selvom dens arbejde allerede er blevet flettet i hovedgrenen? ” . Nå, den eneste løsning på sådanne scenarier er Gå Reflog .
Gennem denne artikel om Git Reflog hjælper jeg digforstå scenarierne, hvor dit arbejde på en filial kan gå tabt, og hvordan du kan genoprette filialen.Denne artikel vil også fremhæve den tilgang, du kan tage for at forhindre utilsigtet tab af en filial, mens du arbejder i et stort projekt.
Så lad os komme i gang med denne artikel.
Overvej et scenarie, en maintainer skal flette mange funktionsgrene fra forskellige samarbejdspartnere og derefter slette dem til sidst, men filialen slettes ved et uheld, før arbejdet kunne flettes?
Før jeg går videre med denne artikel, lad mig fortælle dig, at det ikke er muligt i Git. er sikre og fungerer som et checkpost ikke tillader dig at gøre det. Så dette, hvor Git Reflog kommer ind i billedet.
Hvad er Git Reflog?
Det'Reflog' kommando holder en spor af hver eneste ændring foretaget i referencerne (grene eller tags) i et arkiv og fører en loghistorik over de grene og tags, der enten blev oprettet lokalt eller tjekket ud. Referencelogfiler, som fx snapshotet for kommittet fra, hvornår filialen blev oprettet eller klonet, tjekket ud, omdøbt eller eventuelle forpligtelser, der blev foretaget på grenen, opretholdes af og opført ved kommandoen 'reflog'.
Bemærk: Filialen kan kun gendannes fra din arbejdsmappe, hvis filialen nogensinde har eksisteret i dit lokale arkiv, dvs. filialen blev enten oprettet lokalt eller tjekket ud fra et eksternt lager i dit lokale lager for Git for at gemme sine logfiler til referencehistorik.
Denne kommando skal udføres i det lager, der havde den mistede gren. Hvis du overvejerfjernopbevaringssituation, så skal du udføre reflog-kommandoen på udviklerens maskine, der havde filialen.
kommando: gå reflog
Nu hvor du ved, hvad er Git Reflog, lad osprøv at slette både en flettet og en ikke-flettet gren og se, hvordan Git håndterer det?
Trin 1: Liste over de grene, der flettes til master
Først skal du tjekke ud i ' mestre 'Gren, hvis du er på en anden gren ved hjælp af kommandoen:
$ git checkout master
Produktion
For at få en liste over flettede grene skal du nævne følgende kommando:
$ git gren - flettet
Produktion:
Trin 1.1: Slet derefter den flettede gren:
$ git filial -d udgave # 902
Produktion:
Filialen 'udgave # 902' blev med succes slettet, da den allerede er flettet ind i 'master'-filialen.
Trin 2: Lad os nu liste over de grene, der ikke er slået sammen til master.
$ git filial - ikke-fusioneret
Produktion
Trin 2.2: Lad os endelig slette en ikke-flettet gren med følgende kommando:
$ git gren -d prepod
Hvis du prøver at slette en af grenene med ufærdigt arbejde, sig 'preprod' -grenen, viser git en advarselsmeddelelse.
Produktion
Nu, før jeg fortæller dig, hvordan du kan gendanne dataene i denne artikel på Git Reflog, lad mig fortælle dig, hvad der præcist sker, når en filial bliver slettet, og under hvilke omstændigheder kan filialen gendannes.
Hvordan og hvornår en filial slettes?
Som vi ved, at Git er en Distribueret versionskontrolsystem (DVCS), hver maskine med klonen eller en kopi af arkivet fungerer som begge knude og en knudepunkt . Detteindebærer, at hver maskine har sin egen kopi af hele arkivkoden og historikken.Naturligvis vil du være deling dit arbejde med andre og forlagsvirksomhed det samme.
Derfor kan der i sådanne scenarier være 3 tilfælde, hvor en filial bliver slettet i et virkeligt scenarie med mange bidragydere, der arbejder på et stort projekt. Følgende kan være tilfældene:
Tilfælde 1 - En udvikler kan enten fusionere eller slette filialen
Overvej et scenarie, hvor en udvikler fletter funktionsgrenen ind i hovedgrenen lokalt og derefter sletter funktionsgrenen ved hjælp af ' git gren Kommando med “- d ”Flag som set i de tidligere skærmbilleder.
Kommando: 'Git branch -d branch_name'
Det kan også ske, at udvikleren beslutter at trash ændringerne på grenen og beslutter at slette grenen uden at flette den med nogen anden gren ved hjælp af følgende kommando:
Kommando: 'Git branch -D branch_name'
Med ovenstående kommando er udvikleren detslet kraftigt grenen, der tilsidesætter git-advarslen
$ git gren -D preprod
Produktion
Bemærk : 'Preprod' gren vises ikke længere, når du kører kommandoen 'git branch'. Så yvores arbejde, der er gemt på denne gren, vil gå tabt.
Tilfælde 2 - En udvikler sletter en filial i et delt lager
Overvej et scenarie, hvor en udvikler med læse- / skriveadgang forsøger at slette den eksterne gren med kraftved hjælp af kommandoen “git push” med “–delete” -flagget.
$ git push origin - slet quickfix
Produktion
Bortset fra dette kan der også være et tilfælde, hvor en ikke-autoriseret eller ondsindet bruger tvinger et skub for at slette den eksterne gren.I et sådant tilfælde vil vedligeholderen kun være i stand til at gendanne den slettede 'quickfix'-gren, hvis udviklerenhavde tidligere tjekket ud denne gren. I dette scenario vil dets lokale arkiv stadig have referencelogfiler for det.
Hvis vedligeholderen ikke kan gendanne filialen, skal ejeren af filialen, der slettede den, komme sig fra sine lokale reflogs.
Tilfælde 3 - Et krogscript med super privilegier sletter filialen
Dette kan være en sjælden, men et muligt scenario, hvor et hook-script udløses ved en bestemt git-operationhændelse og kraft sletter de grene, der endnu ikke er flettet. Du kanovervej en af de ovennævnte kommandoer, der er scriptet i et hook-script med sudo-privilegier.
Nu hvor du ved hvad der sker, når du sletter grenen, lad os gå videre med denne artikel om Git Reflog og se, hvordan du gendanner en mistet gren.
Gendan en slettet gren ved hjælp af Git Reflog
Trin 1 : Historiklogfiler over alle referencer
Få en liste over alle de lokale registrerede historiklogfiler til alle referencer ('master', 'uat' og 'prepod') i dette arkiv.
gå reflog
Trin 2 : Identificer historikstemplet
Som du kan henvise til fra ovenstående øjebliksbillede, er Fremhævet forpligtelses-id: e2225bb sammen med HEAD-markørindekset: 4 er den, når ' videresalg Gren blev oprettet fra den nuværende HEAD-markør, der pegede på dit seneste arbejde.
Trin 3 : Gendanne
For at genoprette ‘Videresalg 'Gren brug kommandoen'Git checkout', der passerer HEAD-markørreferencen med indeks-id - 4.Dette er pointerhenvisningen, når 'preprod' gren blev oprettet long commit id fremhævet i output-skærmbilledet.
git checkout -b preprod HEAD @ {4}Produktion
Og voila! ' videresalg 'Filial gendannes tilbage med al din kildekode.
BEMÆRK : Lad mig breakup kommandoen 'git checkout', der er brugt ovenfor, og hjælpe dig med at forstå bedre:
'Git checkout' kommando er en overbelastet kommando (Ligesom enhver Java-overbelastet funktion). Dette er den del, hvor den egentlige filial gendannes.
Denne enkelt kommando tjekker først ud til det tidligere tidsstempel fra historien, der blev påpeget af HEAD @ {4} markør og opretter derefter en gren med navnet 'preprod' ved hjælp af indstillingen '-b' samt skifter din arbejdsmappe til den nyoprettede gren.
Dette indebærer, at den skiftede gren vil være fra 'master' til 'preprod' som angivet i outputskærmen.Du kan nu flette det med 'master' eller 'release' -grenen ifølge din forgreningsmodel.
java cast streng til dato
Nu hvor du ved, hvordan du gendanner en gren, så lad mig fortælle dig, hvilket arbejde der gendannes, når en slettet gren gendannes.
Hvilket arbejde gendannes, når den slettede gren gendannes?
De filer, der blev gemt og gemt på listen med indeksindeks, gendannes tilbage. Usporede filer går tabt. Også jegDet er en god idé at altid iscenesætte og begå dit arbejde eller opbevare dem.
For at hente loghenvisningerne til en bestemt gren eller et tag kør kommandoen - 'git reflog'.
Eksempel: For at kontrollere loghenvisningerne i 'uat' gren alene skal du bruge kommandoen - 'git reflog uat'.
Git Reflog underkommandoer
gå reflog
Kommando til at åbne den manuelle side
$ git reflog - hjælp
Produktion
gå reflog at vise
Viser logfiler for den reference, der er angivet i kommandolinjen.
git reflog show master @ {0}gå reflog udløbe
Denne kommando bruges til at beskære de ældre reflog-poster.
git reflog udløber
gå reflog slet
Denne kommando sletter enkelte poster fra refloghistorikken.
git reflog slet
gå reflog eksisterer
Denne kommando kontrollerer, om en ref (gren eller tag) har en reflog - loghistorikposter.
git reflog findes
Bortset fra de ovennævnte kommandoer tager kommandoen 'Git Reflog' forskellige underkommandoer og forskellige muligheder afhængigt af de ovennævnte underkommandoer. For yderligere læsning kør “ git reflog - hjælp ”Fra terminalvinduet.
Med dette slutter vi denne artikel om Git Reflog.Hensigten med DevOps er at skabe software af bedre kvalitet hurtigere og med mere pålidelighed og samtidig invitere til større kommunikation og samarbejde mellem teams. Hvis du er fascineret af denne artikel, c heck ud af af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka DevOps-certificeringskursus hjælper eleverne med at forstå, hvad der er DevOps og få ekspertise i forskellige DevOps-processer og -værktøjer såsom Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT til automatisering af flere trin i SDLC.
Har du et spørgsmål til os? Nævn det i kommentarfeltet i artiklen 'Git Reflog', så vi vender tilbage til dig ASAP.