Med bommen af teknologi, bliver det uundgåeligt for enhver it-person at arbejde på flere data samtidigt, og dine data er under konstant udvikling med tiden. Det er også vigtigt at spore enhver ændring i dataene og være parat til at fortryde eller tilbagekalde enhver uønsket ændring, når det er nødvendigt.
Jeg må indrømme, at versionering af mine data i Git giver mig mulighed for at være mere eksperimentel i min projektudvikling. Hvis jeg ødelægger, ved jeg, at git altid har en måde at fortryde og / eller vende tilbage til den version af mit projekt, som det var, før jeg skruede op. Hver laget er designet til at tillade, at dataændringerne gennemgås og ændres og / eller korrigeres, før dataene flyttes i næste trin. Så følgende er de fejl, der er dækket af denne blog:
- Fjern scener af filer / mapper fra indeks
- Rediger den sidst forpligtede besked
- Glemte nogle ændringer i den sidste forpligtelse
- Kassér lokale ændringer
- Forpligtede personlige data til det lokale arkiv
- Erstattede den seneste forpligtelse med en ny forpligtelse
- Begik de forkerte data
- Gå tilbage til min gamle projekttilstand
- Gendan en slettet lokalfilial
- Fortryd ændringer foretaget i en forpligtelse
- Gav et forkert navn til min filial
- Ønsker at omarrangere historiklogfiler, inden du skubber til fjernbetjeningen
- Forpligtede ikke-relaterede ændringer til en enkelt forpligtelse
- Skift forfatter-e-mail i alle forpligtelser i alle grene
- Mistede og fundne filer
- Glemt hvilken gren der har mit forpligtelses-id
- Slet en forpligtelse fra historikken
- Skubbet en forkert gren til fjernbetjeningen
Fjern scener af filer / mapper fra indeks
Mens du tilføjer og / eller ændrer filer, har du ofte en tendens til at bruge standardadfærden for kommandoen 'git add', som er at tilføje alle filer og mapper til indekset.Mange gange føler du behovet for at fjerne scener fra bestemte filer eller ændre dem en sidste gang inden du forpligter dig til dem.
Syntaks: git reset
Fjernelse af iscenesættelse af filer fra indeksområdet giver dig en ny chance for at arbejde på dine data igen, inden du forpligter dig til en lokal repo.
Rediger den sidst forpligtede besked
Kommando: git commit --ændre
Du kan redigere den seneste meddelelse om forpligtelse uden at oprette en ny. For at liste forpligtelseslogfilerne har jeg angivet et alias 'hist':
Kommando: git config - global alias.hist 'log --pretty = format: '% C (gul)% h% Creset% ad | % C (grøn)% s% Creset% C (rød)% d% Creset% C (blå) [% an] '- graf - dekorere - dato = kort'x
Du må ikke ændre kommitteringsmeddelelsen, som allerede er skubbet videre til et eksternt lager og delt med andre, da det ville gøre den tidligere begivenhedshistorik ugyldig, og dermed kan ethvert arbejde baseret på det blive påvirket.
Glemte nogle ændringer i den sidste forpligtelse
Lad os sige, at du har glemt at foretage nogle ændringer og allerede har begået dit øjebliksbillede, og du vil heller ikke foretage en anden forpligtelse for at fremhæve din fejl.
Kommando: git commit --ændre
Jeg har fremhævet, hvordan det nylige commit-objekts sha-1-id er genskabt og ændret. Jeg foregav at have forpligtet mig til at blande begge ændringer i én.
Kassér lokale ændringer
Så her er et tilfælde, hvor jeg ændrede 'README'-filen og iscenesatte den. Dernæst ændrede jeg den samme fil en anden gang, men indså, at jeg ikke ønskede den anden ændring.
Lad mig nu ikke fortryde hele ændringen manuelt, jeg kan simpelthen trække den iscenesatte version af filen.
Syntaks:
git checkout -–Lokale ændringer i en fil
git checkout -–Lokale ændringer i alle filerne i telefonbogen & genert & genert
Kommando: git checkout - README
Så jeg kasserede mine sidste ændringer af filen og accepterede den iscenesatte version af filen. I den næste forpligtelse går bare den iscenesatte version af filen i det lokale arkiv.
Forpligtede personlige data til det lokale arkiv
Jeg vil fjerne bestemte data fra det lokale lager, men gemme filerne i arbejdskataloget.
Syntaks:
git reset - blandet HEAD ~
git reset - blandet
Kommando: git reset - blandet HEAD ~ 1
HEAD ~ 1 angiver en forpligtelse lige før den nylige forpligtelse, som den nuværende filial HEAD påpegede.
Filer i det aktuelle øjebliksbillede er fjernet fra både det lokale lager og iscenesættelsesområdet. Tilføj følgende mønstre i den globale .gitignore-fil for at udelukke dem fra at blive sporet af git.
vim ~ / .gitignore_global
# adgangskodefiler #
*.passere
*.nøgle
* .passwd
Med dette fjernes forpligtelsen, der havde øjebliksbillede af adgangskodefiler, og du får et rent iscenesættelsesområde. Mine filer er stadig til stede i min arbejdsmappe, men er ikke længere til stede i det lokale arkiv, men skubbes heller ikke på et eksternt lager.
Advarsel: Hvis du mister dem, kan git ikke gendanne dem for dig, da det ikke ved det.
Erstat den seneste forpligtelse med en ny forpligtelse
Syntaks: git reset --soft [/ HEAD ~ n>]
Indstillingen ‘–soft’ fjern bare de forpligtede filer fra det lokale lager, mens de stadig er iscenesat i indekset, og du kan forpligte dem igen efter en gennemgang. er sha-1 for det øjebliksbillede, du vil fjerne fra den lokale repo. hvor n er antallet af forpligtelser inden HEAD-forpligtelsen
Kommando :git reset - soft HEAD ~ 1
Rediger filer og iscenesæt dem igen
Kommando: git commit -m 'Tilføjelse af index.html og style.css'
Din forpligtelseshistorik viser sig nu at være:
Begik de forkerte data
Syntaks:
git reset - hårdt HOVED ~ n–Indstil projektet til at 'n' forpligter sig inden det seneste begåede øjebliksbillede
git reset - hårdt–Nulstil projektet til det givne commit id-øjebliksbillede
Kommando: git reset - hårdt HOVED ~ 1
Den seneste forpligtelse og de korrupte filer fjernes fra det lokale lager, mellemstationer såvel som arbejdsmappen.
kan du udvide og implementere i java
Advarsel: Det er en farlig kommando, da du ender med at miste filer i arbejdskataloget. Ikke anbefalet i et eksternt delt lager.
Gå tilbage til min gamle projekttilstand
Du kan gå til en ældre tilstand af dit projekt i tidens historie. Hvis du ødelægger i den nyeste version eller har brug for forbedringer i ældre kode, kan du oprette en anden gren ud af det gamle projekt-øjebliksbillede for ikke at hindre dit nuværende arbejde. Lad os se hvordan:
en. Angiv projekthistorikken, og vælg det ældre commit-id, kommandoen:gå hist b. Opret en anden gren ud af forpligtelses-id'et:
git checkout -b old-state e7aa9a5
c. Fortsæt med at arbejde på koden og sammenflet / rebase senere med 'master'-grenen.
Gendan en slettet lokalfilial
Det er muligt at regenerere det tabte arbejde på en referencegren. Sig, jeg slettede grenen 'old_code' uden at flette med hovedgrenen og mistede arbejdet. Og nej, jeg skubbede heller ikke grenen til et eksternt lager, hvad så? Nå git spor, og hold en journalpost over alle ændringer foretaget på hver reference, lad os se mine:gå reflog
Så HEAD @ {2} er markøren, da jeg flyttede til 'old_code' gren, lad os gendanne det:
Syntaks:git checkout -b
Kommando:git checkout -b old_code HEAD @ {2}
Du skal nu være i 'old_code' -grenen med dit seneste arbejde på tidspunktet for dets oprettelse. Derudover var 'reflog' -markøren ved HEAD @ {1} den seneste forpligtelse, der blev foretaget på grenen 'old_code'. For at gendanne denne unikke begå bare kør kommandoen som:git reset - hard HEAD @ {1}.Dette gendanner også de ændrede filer i arbejdskataloget.
Hvis du ønsker at vide detaljeret, hvordan denne kommando fungerer, og hvordan kan du administrere 'reflog'-poster, kan du lige så godt læse mit tidligere indlæg pågendannelse af den slettede gren fra git reflog.
Fortryd ændringer foretaget i en forpligtelse
gåvende tilbagebruges til at registrere nogle nye forpligtelser for at vende effekten af nogle tidligere forpligtelser.
Syntaks: git vende tilbage
Fra mine forpligtelseslogfiler vil jeg gerne vende den ændring, der er foretaget i det fremhævede commit-id:
Kommando: git gendanne 827bc0d
Det er bedre, at du ikke nulstiller '–hardt' de delte forpligtelser, men i stedet 'git revert' dem for at bevare historikken, så det bliver lettere for alle at spore historikloggene for at finde ud af, hvad der blev tilbageført, af hvem og hvorfor?
Du kan bruge den samme logik til at henvise forpligtelserne vedrørende HEAD-markøren i stedet for at give kommit-id'et, som i HEAD ~ 3 eller HEAD ~ 4 og så videre.
Gav et forkert navn til min filial
Du kan omdøbe et lokalt filialnavn. Det sker så mange gange, at du måske ønsker at omdøbe din filial baseret på det problem, du arbejder på uden at gå igennem smerten ved at migrere alt dit arbejde fra et sted til et andet. For eksempel kan du enten være på den samme gren eller en anden gren og stadig være i stand til at omdøbe den ønskede gren som vist nedenfor:
Syntaks: git gren -m
Kommando: git branch -m old_code old_ # 4920
trin for trin tutorial
Som du måske undrer dig over, holder git styr på dette omdøb? Ja, det refererer til dine 'reflog'-poster, her er min:
Omdøbning af en filial påvirker ikke dens fjernsporingsfilial. Vi skal se i afsnittet om fjernbetjening, hvordan man udskifter en gren på fjernlageret
Omarranger historiklogfiler, inden du skubber til fjernbetjeningen
Hvordan ville jeg ønske, at jeg ville have foretaget visse forpligtelser tidligere end andre og slet ikke havde forpligtet mig. Interaktivt omarrangere og redigere de gamle forpligtelser for effektivt at rette op eller forbedre koden
Syntaks: git rebase -i
Kommando: git rebase -i fb0a90e–Start med at rebase de forpligtelser, der blev foretaget efter commit-id fb0a90e
Genbesøg git rebase dokumentation for at forstå, hvordan en '–interaktiv eller -i' rebase adskiller sig fra en almindelig rebase.
Forpligtede ikke-relaterede ændringer til en enkelt forpligtelse
I dette tilfælde skal du dele en gammel begravet forpligtelse i flere logiske forpligtelser.
Syntaks: git rebase -i
Kommando: git rebase -i fb0a90e
I rebase-editoren skal du vælge e7aa9a5 commit id og ændre det til 'edit' i stedet for 'pick'.
Du ville nu være i projektets version af commit id-e7aa9a5. Nulstil først forpligtelseshistorikken og iscenesættelsesområdet til den tidligere kommando-kommando:git reset HEAD ~ 1
For det andet skal du redigere + trin + begå filerne individuelt
Kommandoer:
git tilføj kode && git commit -m 'Tilføjelse af indledende koder'
git tilføj ny kode && git commit -m 'Tilføjelse af ny kode'
For det tredje skal du fortsætte rebasen og afslutte.
Kommando :git rebase - fortsæt
For det fjerde skal du se historikken med yderligere forpligtelser.
Kommando: gå hist
Skift forfatter-e-mail i alle forpligtelser i alle grene
Jeg har versioneret og begået mine projektfiler i git siden lang tid nu, men indtil nu slog det mig aldrig, at min e-mail-id var kompromitteret i mine log-logfiler, der endda blev offentliggjort på eksterne arkiver. Nå, dette kan ske for alle, når du oprindeligt konfigurerer konfigurationerne i '.gitconfig' -filen. Til min relief-git kan skriv om de miljøvariabler, vi leverer, når vi opretter et commit-objekt.
Først får jeg listen over e-mail-id'er at beslutte dem, jeg vil ændre:
Kommando: git log --all --pretty = format: '% an% d'–Dette udskriver forfatter-navn (refname / gren-navn)
For det andet løber jeg igennem hver forpligtelse på hver gren og omskriv forpligtelsesobjektet med det nye e-mail-id
Kommando:
git filter-gren --env-filter '
hvis ['$ GIT_AUTHOR_NAME' = 'divya']
derefter
GIT_AUTHOR_EMAIL = 'divya@github.com'
være
' -- --alle
Mistede og fundne filer
Antag at du har mistet en bestemt fil, og at du ikke kan huske dens navn, men kunne huske visse ord i filen. I dette tilfælde kan du følge disse trin-
Trin 1: Angiv alle de forpligtelser, der nogensinde indeholdt filens øjebliksbillede med det søgte mønster
Kommando :git rev-list --all | xargs git grep -i 'tidsstempel'
Trin 2 : Opret en ny gren 'mistet-fundet' fra dette fremhævede commit-id
Syntaks: git checkout -b mistet-fundet d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Glemt hvilken gren der har mit forpligtelses-id
Til tider, efter at du har registreret et buggy commit-id, kan du lige så godt ønske at kende alle de grene, der har denne forpligtelse på sig, så du kan ordne dem alle. Det er ikke særlig praktisk at tjekke hver grenes historie i et stort projekt med flere grene.
En dårlig forpligtelse lavet i min navigationsbygningsapplikation brød engang koden, det var da jeg brugte 'Git bisect' kommando til at opdage kommit-id'et, der var dårligt efterfulgt afkommando:git gren - indeholderat angive grene med den dårlige forpligtelse.
Så nu kender jeg alle de grene, der stadig har den dårlige forpligtelse, jeg kunne enten vende tilbage eller nulstille denne ændringssæt.
Slet en forpligtelse fra historikken
Nogle gange føler jeg behov for bare at udslette en forpligtelse fra historien og ikke efterlade spor af den. Jeg vil ikke anbefale dig at prøve dette stunt på en delt filial, men kun på din lokale filial.
Syntaks: git rebase -i
Kommando :git rebase -i 93859d8
I rebase-editoren-> udskift 'edit' med 'drop' for det fremhævede commit-id: 69f4813
I nogle af tilfældene kan denne omskrivning resultere i konflikter. Du skal løse konflikter og derefter gå videre.
Advarsel : Dette er en farlig kommando, da dette omskriver historik og kan miste data. En sådan gren adskiller sig fra dens eksterne modstykke og skal skubbes med--krafteller- tvang-med-leasingmulighed.
Skubbet en forkert gren til fjernbetjeningen
Nu, her er hvad jeg vil gøre - jeg vil slette en fjerntliggende gren og stop også med at spore det fra min lokale filial. 'git push'Kommando, når den bruges sammen med- sletoption sletter den eksterne gren Så det er sådan, jeg får den lokale kopi af det klonede projekt -
git-klon https://github.com/greets/myProj.git
cd myProj
En gang slettes fjerngrenen andre på den delte repo skal opdatere og opdatere deres fjernreferencer med- beskæremulighed for at slette de manglende objektreferencer:git hente - beskære -v oprindelse
I dette indlæg har jeg nævnt nogle af de almindelige fejl eller ændringer, som git kan hjælpe dig med at rette. Hver kode er unik og udviklet på sin måde, så der er også forskellige måder at nærme sig og løse et problem på. Du kan altid henvise til embedsmanden git-dokumentation at forstå, hvordan forskellige git-kommandoer beskytter din kildekode, og hvordan du bruger kommandoerne på den bedst mulige måde.
Nu hvor du har forstået de almindelige Git-fejl, skal du tjekke dette 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-certificeringstræningskurset 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 denne “almindelige Git-fejl”, så vender vi tilbage til dig