Med bommen av teknologi, blir det uunngåelig for enhver IT-person å jobbe med flere data samtidig, og dataene dine er i stadig utvikling med tiden. Det er også viktig å spore alle endringer i dataene og være forberedt på å angre eller tilbakekalle enhver uønsket endring når det er nødvendig.
Jeg må innrømme at versjon av dataene mine i Git tillater meg å være mer eksperimentell i prosjektutviklingen min. Hvis jeg roter meg, vet jeg at git alltid har en måte å angre og / eller tilbakestille den versjonen av prosjektet mitt slik det var før jeg skrudde opp. Hver laget er utformet slik at dataendringene kan gjennomgås og modifiseres og / eller korrigeres før dataene flyttes i neste trinn. Så følgende er feilene som dekkes i denne bloggen:
- Fjern filer / kataloger fra Index
- Rediger den sist engasjerte meldingen
- Glemte noen endringer i den siste forpliktelsen
- Kast lokale endringer
- Forpliktet personlige data til det lokale depotet
- Erstatt den siste forpliktelsen med en ny forpliktelse
- Begikk feil data
- Gå tilbake til min gamle prosjekttilstand
- Gjenopprett en slettet lokal filial
- Angre endringer som er gjort i en forpliktelse
- Ga feil navn til grenen min
- Ønsker å omorganisere historikklogger før du skyver til fjernkontrollen
- Forpliktet ubeslektede endringer i en enkelt forpliktelse
- Endre forfatter-e-post i alle forpliktelser i alle grener
- Mistede og funnet filer
- Glemte hvilken gren som har mitt kommisjons-ID
- Slett en forpliktelse fra historikken
- Skyv en feil gren til fjernkontrollen
Fjern filer / kataloger fra Index
Mens du legger til og / eller endrer filer, pleier du ofte å bruke standardoppførselen til kommandoen ‘git add’, som er å legge til alle filer og kataloger i indeksen.Mange ganger føler du behovet for å fjerne scenen eller endre dem en siste gang før du forplikter dem.
Syntaks: git reset
Un-iscenesettelse av filer fra indeksområdet gir deg en ny sjanse til å jobbe på dataene dine igjen før du forplikter deg til en lokal repo.
Rediger den sist engasjerte meldingen
Kommando: git commit --endre
Du kan redigere den siste meldingen uten å opprette en ny. For å liste opp forpliktelsesloggene, har jeg angitt et alias 'hist':
Kommando: git config --global alias.hist 'log --pretty = format: '% C (gul)% h% Creset% ad | % C (grønn)% s% Creset% C (rød)% d% Creset% C (blå) [% an] '- graf - dekorere - dato = kort'x
Ikke endre kommisjonsmeldingen som allerede er presset videre til et eksternt arkiv og delt med andre, da det vil gjøre den tidligere kommitteringshistorikken ugyldig og dermed kan alt arbeid basert på det bli påvirket.
Glemte noen endringer i den siste forpliktelsen
La oss si at du har glemt å gjøre noen modifikasjoner og allerede har begått øyeblikksbildet ditt. Du vil heller ikke gjøre en annen forpliktelse for å markere feilen din.
Kommando: git commit --endre
Jeg har fremhevet hvordan sha-1-IDen til det siste kommittobjektet er blitt gjenskapt og endret. Jeg lot som om jeg hadde forpliktet meg til å blande begge endringene i en.
Kast lokale endringer
Så her er et tilfelle der jeg modifiserte 'README'-filen og iscenesatte den. Deretter endret jeg den samme filen en gang til, men innså at jeg ikke ønsket den andre endringen.
La meg ikke angre hele endringen manuelt, jeg kan bare trekke den iscenesatte versjonen av filen.
Syntaks:
git checkout -–Lokale endringer i en fil
git checkout -–Lokale endringer i alle filene i katalogen og sjenerte og sjenerte
Kommando: git checkout - README
Så jeg forkastet de siste endringene mine i filen og godtok den iscenesatte versjonen av filen. I neste kommisjon går bare den iscenesatte versjonen av filen i det lokale depotet.
Forpliktet personlige data til det lokale depotet
Jeg vil fjerne visse data fra det lokale depotet, men beholde filene i arbeidskatalogen.
Syntaks:
git reset - blandet HEAD ~
git reset - blandet
Kommando: git reset - blandet HEAD ~ 1
HEAD ~ 1 indikerer en forpliktelse rett før den nylige forpliktelsen pekt av den nåværende avdelingen HEAD.
Filer i gjeldende øyeblikksbilde er fjernet fra både det lokale depotet og iscenesettelsesområdet. Legg til følgende mønstre i den globale .gitignore-filen for å ekskludere dem fra å bli sporet av git.
vim ~ / .gitignore_global
# passordfiler #
*.sende
*.nøkkel
* .passwd
Med dette fjernes forpliktelsen som hadde øyeblikksbildet av passordfiler, og du får et rent iscenesettingsområde. Filene mine er fremdeles til stede i arbeidskatalogen min, men ikke lenger til stede i det lokale depotet, og blir heller ikke presset på et eksternt depot.
Forsiktighet: Hvis du mister dem, kan git ikke gjenopprette dem for deg, da det ikke vet om det.
Erstatt den siste forpliktelsen med en ny forpliktelse
Syntaks: git reset --soft [/ HEAD ~ n>]
Alternativet ‘–soft’ fjerner bare de forpliktede filene fra det lokale depotet mens de fremdeles er iscenesatt i indeksen, og du kan forplikte dem på nytt etter en gjennomgang. er sha-1 av øyeblikksbildet du vil fjerne fra den lokale repoen. hvor n er antall forpliktelser før HEAD-forpliktelsen
anvendelser av stor dataanalyse
Kommando :git reset - soft HEAD ~ 1
Endre filer og iscenesett dem igjen
Kommando: git commit -m 'Legge til index.html og style.css'
Forpliktelseshistorikken din viser seg nå å være:
Begikk feil data
Syntaks:
git reset --hard HEAD ~ n–Sett prosjektet til ‘n’ forplikter før det siste engasjerte øyeblikksbildet
git reset --hard– Tilbakestill prosjektet til gitt id-øyeblikksbilde
Kommando: git reset - hard HEAD ~ 1
Den siste forpliktelsen og de korrupte filene blir fjernet fra det lokale depotet, iscenesettelsesområdet samt arbeidskatalogen.
Forsiktighet: Det er en farlig kommando da du ender med å miste filer i arbeidskatalogen. Ikke anbefalt på et eksternt delt depot.
Gå tilbake til min gamle prosjekttilstand
Du kan komme til en eldre del av prosjektet ditt i tidens historie. Hvis du roter i den siste versjonen eller trenger forbedringer i eldre kode, kan det være lurt å opprette en annen gren ut av det gamle øyeblikksbildet for å ikke hindre det nåværende arbeidet ditt. La oss se hvordan:
en. Oppgi prosjekthistorikken og bestem hvilken eldre kommisjons-ID, kommando:gå hist b. Opprett en annen gren ut av kommisjons-ID:
git checkout -b old-state e7aa9a5
c. Fortsett å jobbe med koden og slå sammen / rebase senere med 'master' -grenen.
Gjenopprett en slettet lokal filial
Det er mulig å regenerere det tapte arbeidet på en referansegren. Si, jeg slettet grenen ‘old_code’ uten å slå seg sammen med hovedgrenen og mistet arbeidet. Og nei, jeg presset ikke grenen til et eksternt lager heller, hva da? Vel git spor og hold en journaloppføring av alle endringene som er gjort på hver referanse, la oss se mine:gå reflog
Så HEAD @ {2} er pekeren da jeg flyttet til grenen 'old_code', la oss gjenopprette det:
Syntaks:git checkout -b
Kommando:git checkout -b old_code HEAD @ {2}
Du må være i 'old_code' -grenen med det siste arbeidet ditt da det ble opprettet. I tillegg var 'reflog' -pekeren på HEAD @ {1} den siste forpliktelsen som ble gjort på grenen 'old_code'. For å gjenopprette denne unike commit bare kjør kommandoen som:git reset --hard HEAD @ {1}.Dette gjenoppretter også de modifiserte filene i arbeidskatalogen.
hvordan du endrer dobbelt til int i java
Hvis du ønsker å vite i detalj hvordan denne kommandoen fungerer, og hvordan kan du administrere ‘reflog’ oppføringene, kan du like godt lese mitt tidligere innlegg pågjenopprette den slettede grenen fra git reflog.
Angre endringer som er gjort i en forpliktelse
gåtilbakestillebrukes til å registrere noen nye forpliktelser for å reversere effekten av noen tidligere forpliktelser.
Syntaks: git tilbakevend
Fra forpliktelsesloggene mine vil jeg reversere endringen som er gjort i den uthevede kommisjons-ID:
Kommando: git tilbakevend 827bc0d
Det er bedre at du ikke tilbakestiller '–hard' den delte forplikter, men i stedet 'git revert' dem for å bevare historikken, slik at det blir lettere for alle å spore opp loggene for å finne ut hva som ble tilbakeført, av hvem og hvorfor?
Du kan bruke den samme logikken for å henvise forpliktelsene til HEAD-pekeren i stedet for å gi kommisjons-ID, som i HEAD ~ 3 eller HEAD ~ 4 og så videre.
Ga feil navn til grenen min
Du kan gi nytt navn til et lokalt filialnavn. Det skjer så mange ganger at du kanskje vil gi nytt navn til filialen din basert på problemet du jobber med uten å gå gjennom smerten ved å migrere alt arbeidet ditt fra ett sted til et annet. For eksempel kan du enten være på samme gren eller en annen gren og fremdeles kunne gi nytt navn til ønsket gren som vist nedenfor:
Syntaks: git gren -m
Kommando: git branch -m old_code old_ # 4920
Som du kanskje lurer på, holder git oversikt over dette omdøpet? Ja, det refererer til 'reflog' oppføringene dine, her er mine:
Å gi nytt navn til en filial vil ikke påvirke den eksterne sporingsgrenen. Vi skal se i fjernseksjonen hvordan du bytter ut en gren på det eksterne depotet
Ordne historikkloggene på nytt før du skyver til fjernkontrollen
Hvordan jeg skulle ønske jeg ville ha gjort visse forpliktelser tidligere enn andre og ikke ville ha gjort noen forpliktelser i det hele tatt. Omorganiser og rediger de gamle forpliktelsene interaktivt for effektivt å fikse opp eller forbedre koden
Syntaks: git rebase -i
Kommando: git rebase -i fb0a90e–Begynn å omsette forpliktelsene som ble gjort etter commit-id fb0a90e
Gå tilbake til git rebase dokumentasjon for å forstå hvordan er en ‘–interaktiv eller -i’ rebase forskjellig fra en vanlig rebase.
Forpliktet ubeslektede endringer i en enkelt forpliktelse
I dette tilfellet må du dele en gammel begravd forpliktelse i flere logiske forpliktelser.
Syntaks: git rebase -i
Kommando: git rebase -i fb0a90e
I rebase-redigereren må du velge e7aa9a5 commit id og endre den til 'edit' i stedet for 'pick'.
Du vil nå være i prosjektets versjon av commit id-e7aa9a5. Tilbakestill først forpliktelseshistorikken og iscenesettingsområdet til den forrige kommittoen:git reset HEAD ~ 1
For det andre, rediger + trinn + forplikt filene hver for seg
Kommandoer:
git add code && git commit -m 'Legge til innledende koder'
git legg til ny kode && git commit -m 'Legge til ny kode'
For det tredje, fortsett rebase og slutt.
Kommando :git rebase - fortsett
For det fjerde, se historikken med ekstra forpliktelser.
Kommando: gå hist
Endre forfatter-e-post i alle forpliktelser i alle grener
Jeg har versjonert og begått prosjektfilene mine i git siden lenge, men inntil nå slo det meg aldri at e-post-ID-en min kompromittert i forpliktelsesloggene mine, som til og med blir publisert på eksterne arkiver. Vel, dette kan skje med hvem som helst når du opprinnelig konfigurerte konfigurasjonene i '.gitconfig' -filen. Til min lettelse kan git omskrive miljøvariablene vi gir når vi lager et kommittobjekt.
Først får jeg listen over e-post-ID-er å bestemme de jeg vil endre:
Kommando: git log --all --pretty = format: '% an% d'–Dette skriver ut forfatternavn (refname / branch-name)
For det andre løper jeg gjennom hver forpliktelse på hver gren og skriv forpliktelsesobjektet på nytt med den nye e-post-ID-en
Kommando:
git filter-branch --env-filter '
hvis ['$ GIT_AUTHOR_NAME' = 'divya']
deretter
GIT_AUTHOR_EMAIL = 'divya@github.com'
være
' -- --alle
hvordan du gjør dobbelt til int
Mistede og funnet filer
Anta at du har mistet en bestemt fil, og at du ikke husker navnet, men kan huske visse ord i filen. I dette tilfellet kan du følge disse trinnene-
Trinn 1: Skriv opp alle forpliktelsene som noen gang inneholdt filbildet med det søkte mønsteret
Kommando :git rev-list --all | xargs git grep -i 'tidsstempel'
Steg 2 : Opprett en ny gren ‘mistet-funnet’ fra denne uthevede forpliktelses-iden
Syntaks: git checkout -b tapt-funnet d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Glemte hvilken gren som har mitt kommisjons-ID
Noen ganger, etter at du har oppdaget en buggy-forpliktelses-ID, kan du like gjerne vite alle grenene som har denne forpliktelsen på seg, slik at du kan fikse dem alle. Å sjekke ut hver grenes historie er ikke veldig praktisk i et stort prosjekt med flere filialer.
En dårlig forpliktelse som ble gjort i applikasjonen for navigasjonsbygging, brøt en gang koden, det var da jeg brukte ‘Git bisect’ kommando for å oppdage kommisjons-ID som var dårlig etterfulgt avkommando:git gren - inneholderå liste opp grenene med den dårlige forpliktelsen.
Så nå vet jeg alle grenene som fremdeles har dårlig forpliktelse, jeg kan enten tilbakestille eller tilbakestille denne endringssettet.
Slett en forpliktelse fra historikken
Noen ganger føler jeg behovet for å bare utslette en forpliktelse fra historien og ikke etterlate noe spor av den. Jeg vil ikke anbefale deg å prøve dette stuntet på en delt gren, men bare på din lokale gren.
Syntaks: git rebase -i
Kommando :git rebase -i 93859d8
I rebase editor-> erstatt ‘edit’ med ‘drop’ for den uthevede forpliktelses-id: 69f4813
I noen av tilfellene kan denne omskrivingen føre til konflikter. Du må løse konflikter og deretter gå videre.
Advarsel : Dette er en farlig kommando da dette omskriver historikk og kan miste data. En slik gren er forskjellig fra den eksterne motparten og må presses med--makteller- force-with-leasealternativ.
Skyv en feil gren til fjernkontrollen
Nå, her er hva jeg vil gjøre - jeg vil slette en ekstern gren og også slutte å spore den fra min lokale filial. ’git push‘Kommando når den brukes med- slettalternativet sletter den eksterne grenen Så dette er hvordan jeg får den lokale kopien av det klonede prosjektet -
git klone https://github.com/greets/myProj.git
cd myProj
En gang slettes den eksterne grenen, andre på den delte repoen må oppdatere og oppdatere sine eksterne referanser med--sviskealternativ for å slette manglende objektreferanser:git fetch - beskjære -v opprinnelse
I dette innlegget har jeg nevnt noen av de vanlige feilene eller endringene som git kan hjelpe deg med å fikse. Hver kode er unik og utviklet på sin måte, så det er også forskjellige måter å nærme seg og fikse et problem på. Du kan alltid henvise til tjenestemannen git dokumentasjon for å forstå hvordan forskjellige git-kommandoer beskytter kildekoden din og hvordan du bruker kommandoene på en best mulig måte.
Nå som du har forstått de vanlige Git-feilene, sjekk ut dette av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka DevOps Certification Training-kurset hjelper elever til å forstå hva som er DevOps og få ekspertise i forskjellige DevOps-prosesser og verktøy som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT for å automatisere flere trinn i SDLC.
Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet i denne 'vanlige Git-feilen', så kommer vi tilbake til deg