Med bommen av teknik blir det oundvikligt för alla IT-personer att arbeta med flera data samtidigt och dina data utvecklas ständigt med tiden. Det är också viktigt att spåra varje förändring i data och vara beredd att ångra eller återställa alla oönskade ändringar vid behov.
Jag måste erkänna att versionering av mina data i Git gör att jag kan vara mer experimentell i min projektutveckling. Om jag trasslar, vet jag att git alltid har ett sätt att ångra och / eller återställa den versionen av mitt projekt som det var innan jag slog till. Varje lagret är utformat så att dataändringarna kan granskas och modifieras och / eller korrigeras innan data flyttas i nästa steg. Så följande är de misstag som behandlas i den här bloggen:
- Ta bort filer / kataloger från Index
- Redigera det senaste meddelandet
- Glömde några ändringar i det senaste åtagandet
- Kasta lokala ändringar
- Engagerade personuppgifter till det lokala förvaret
- Ersatte det senaste åtagandet med ett nytt åtagande
- Begick fel data
- Gå tillbaka till mitt gamla projekt
- Återställ en borttagen lokalfilial
- Ångra ändringar som gjorts i ett engagemang
- Gav ett fel namn till min filial
- Vill du ordna om historikloggar innan du trycker på fjärrkontrollen
- Gjorde icke-relaterade ändringar i en enda förpliktelse
- Ändra författar-e-post i alla åtaganden i alla grenar
- Borttappade och hittade filer
- Glömde vilken gren som har mitt engagemangs-id
- Ta bort ett engagemang från historiken
- Skjutit en fel gren till fjärrkontrollen
Ta bort filer / kataloger från Index
När du lägger till och / eller ändrar filer brukar du ofta använda standardbeteendet för kommandot 'git add', vilket är att lägga till alla filer och kataloger i indexet.Många gånger känner du behovet av att avspela vissa filer eller ändra dem en sista gång innan du gör dem.
Syntax: git reset
Att avinstallera filer från indexområdet ger dig en ny chans att arbeta vidare med dina data innan du gör en lokal repo.
Redigera det senaste meddelandet
Kommando: git commit --ändra
Du kan redigera det senaste meddelandet utan att skapa ett nytt. För att lista upptagningsloggarna har jag ställt in ett alias 'hist':
Kommando: git config - globalt alias.hist 'log --pretty = format: '% C (gul)% h% Creset% ad | % C (grön)% s% Creset% C (röd)% d% Creset% C (blå) [% an] '- graf - dekorera - datum = kort'x
Ändra inte kommuniceringsmeddelandet som redan har skjutits vidare till ett fjärrförvar och delats med andra, eftersom det skulle göra den tidigare historikens ogiltighetshistorik ogiltig och därmed eventuellt arbete baserat på det kan påverkas.
Glömde några ändringar i det senaste åtagandet
Låt oss säga att du har glömt att göra några ändringar och redan begått din ögonblicksbild, du vill inte heller göra ett nytt åtagande för att markera ditt misstag.
Kommando: git commit --ändra
Jag har belyst hur det senaste kommitténs objekt sha-1-id har återskapats och ändrats. Jag låtsades ha gjort ett enda åtagande och blandade båda ändringarna i en.
Kasta lokala ändringar
Så här är ett fall där jag modifierade filen 'README' och arrangerade den. Därefter ändrade jag samma fil en andra gång men insåg att jag inte ville ha den andra ändringen.
Låt mig inte ångra hela ändringen manuellt, jag kan helt enkelt dra den iscensatta versionen av filen.
Syntax:
git checkout -–Lokala förändringar i en fil
git checkout -–Lokala förändringar i alla filer i katalogen & blyg & blyg
Kommando: git checkout - LÄS
Så jag kastade bort mina senaste ändringar av filen och accepterade den iscensatta versionen av filen. I nästa engagemang går bara den iscensatta versionen av filen i det lokala arkivet.
Engagerade personuppgifter till det lokala förvaret
Jag vill ta bort viss data från det lokala förvaret men behålla filerna i arbetskatalogen.
Syntax:
git reset - blandat HEAD ~
git reset - blandat
Kommando: git reset - blandat HEAD ~ 1
HEAD ~ 1 indikerar ett engagemang strax före det senaste engagemanget som pekats av den aktuella filialen HEAD.
Filer i den aktuella ögonblicksbilden har tagits bort från både det lokala förvaret och iscensättningsområdet. Lägg till följande mönster i den globala .gitignore-filen för att utesluta att de spåras av git.
vim ~ / .gitignore_global
# lösenordsfiler #
*.passera
*.nyckel
* .passwd
Med detta tas bort åtagandet som hade ögonblicksbilden av lösenordsfiler, och du får ett rent mellanrum. Mina filer finns fortfarande i min arbetskatalog men finns inte längre i det lokala förvaret, de kommer inte heller att tryckas på ett fjärrförvar.
Varning: Om du tappar dem kan git inte återställa dem åt dig eftersom det inte vet om det.
Ersätt det senaste engagemanget med ett nytt engagemang
Syntax: git reset --soft [/ HEAD ~ n>]
Alternativet ”–soft” tar bara bort de engagerade filerna från det lokala förvaret medan de fortfarande är iscensatta i indexet och du kan begå dem igen efter en granskning. är sha-1 för ögonblicksbilden som du vill ta bort från den lokala repo. där n är antalet åtaganden innan HEAD-åtagandet
Kommando :git reset --soft HEAD ~ 1
Ändra filer och iscensätta dem igen
Kommando: git commit -m 'Lägga till index.html och style.css'
Din åtagandeshistorik visar sig nu vara:
Begick fel data
Syntax:
git reset - hård HEAD ~ n–Återställ projektet till ”n” åtaganden före den senaste engagerade ögonblicksbilden
git reset - hårt–Återställ projektet till en given snap-id-ögonblicksbild
Kommando: git reset - hård HEAD ~ 1
Det senaste engagemanget och de korrupta filerna tas bort från det lokala förvaret, iscensättningsområdet samt arbetskatalogen.
lookup transformation i informatica exempel
Varning: Det är ett farligt kommando eftersom du slutar förlora filer i arbetskatalogen. Rekommenderas inte i ett fjärrdelat arkiv.
Gå tillbaka till mitt gamla projekt
Du kan gå till en äldre del av ditt projekt i tidens historia. Om du trasslar i den senaste versionen eller behöver förbättringar i äldre kod kanske du vill skapa en ny gren av den gamla projektbilden för att inte hindra ditt nuvarande arbete. Låt oss se hur:
a. Lista ut projekthistoriken och besluta om det äldre kommitté-id: t, kommandot:gå hist b. Skapa en ny gren från kommit-id:
git checkout -b old-state e7aa9a5
c. Fortsätt arbeta med koden och slå sedan ihop / rebase senare med 'master' -grenen.
Återställ en borttagen lokalfilial
Det är möjligt att regenerera det förlorade arbetet på en referensgren. Säg, jag raderade grenen 'gammal_kod' utan att gå samman med huvudgrenen och förlorade arbetet. Och nej, jag pressade inte filialen till ett fjärrförvar heller, vad då? Nåväl git spår och håll en journalpost över alla ändringar som gjorts i varje referens, låt oss se mina:gå igen
Så, HEAD @ {2} är pekaren när jag flyttade till grenen 'old_code', låt oss återställa det:
Syntax:git kassan -b
Kommando:git kassan -b old_code HEAD @ {2}
Du måste vara i 'old_code' -grenen med ditt senaste arbete vid tidpunkten för dess skapande. Dessutom var 'reflog' -pekaren på HEAD @ {1} det senaste åtagandet som gjordes för 'old_code' -grenen. begå bara kör kommandot som:git reset --hard HEAD @ {1}.Detta återställer också de modifierade filerna i arbetskatalogen.
Om du vill veta mer i detalj hur detta kommando fungerar och hur du kan hantera 'reflog' -posterna kan du lika gärna läsa mitt tidigare inlägg pååterställa den raderade grenen från git reflog.
Ångra ändringar som gjorts i ett engagemang
gååtergåanvänds för att spela in några nya åtaganden för att vända effekten av vissa tidigare åtaganden.
Syntax: git återgå
Från mina åtagandeloggar vill jag vända ändringen som gjorts i det markerade engagemangs-id:
Kommando: git återgå 827bc0d
Det är bättre att du inte återställer '–hård' de delade åtagandena, utan istället 'git revert' dem för att bevara historiken så att det blir lättare för alla att spåra historikloggarna för att ta reda på vad som återställts, av vem och varför?
Du kan använda samma logik för att hänvisa åtagandena angående HEAD-pekaren istället för att ge engagemangs-id, som i HEAD ~ 3 eller HEAD ~ 4 och så vidare.
Gav ett fel namn till min filial
Du kan byta namn på ett lokalt filialnamn. Det händer så många gånger att du kanske vill byta namn på din filial baserat på det problem du arbetar med utan att gå igenom smärtan med att migrera allt ditt arbete från en plats till en annan. Till exempel kan du antingen vara på samma gren eller en annan gren och ändå kunna byta namn på önskad gren som visas nedan:
Syntax: git gren -m
Kommando: git branch -m old_code old_ # 4920
Som du kanske undrar håller git koll på detta namn? Ja, det hänvisar till dina 'reflog'-poster, här är min:
Att byta namn på en filial påverkar inte dess filial för fjärrspårning. Vi kommer att se i fjärrsektionen hur man byter ut en gren på fjärrförvaret
Ordna om historikloggarna innan du trycker på fjärrkontrollen
Hur önskar jag att jag skulle ha gjort vissa åtaganden tidigare än andra och inte skulle ha gjort några åtaganden alls. Interaktivt ordna om och redigera de gamla åtagandena för att effektivt fixa eller förbättra koden
Syntax: git rebase -i
Kommando: git rebase -i fb0a90e–Börja omstarta de åtaganden som gjordes efter commit-id fb0a90e
Återbesök git rebase dokumentation för att förstå hur skiljer sig en ”–interaktiv eller -i” rebase från en vanlig rebase.
Gjorde icke-relaterade ändringar i en enda förpliktelse
I det här fallet måste du dela ett gammalt begravt engagemang i flera logiska åtaganden.
Syntax: git rebase -i
Kommando: git rebase -i fb0a90e
I rebase-redigeraren måste du välja e7aa9a5 commit id och ändra det till 'edit' istället för 'pick'.
Du skulle nu vara i projektets version av commit id-e7aa9a5. Återställ först åtagandeshistoriken och iscenesättningsområdet till det föregående kommittén:git reset HEAD ~ 1
För det andra, redigera + steg + begå filerna individuellt
Kommandon:
git add code && git commit -m 'Lägga till initiala koder'
git lägg till ny kod && git commit -m 'Lägga till ny kod'
För det tredje, fortsätt rebasen och avsluta.
Kommando :git rebase - fortsätt
För det fjärde, se historiken med ytterligare åtaganden.
Kommando: gå hist
Ändra författar-e-post i alla åtaganden i alla grenar
Jag har versionerat och begått mina projektfiler i git sedan länge nu, men fram till nu slog det mig aldrig att mitt e-post-ID komprometterades i mina logghistoriska loggar som till och med publiceras på fjärrförråd. Det kan hända vem som helst när du först konfigurerar konfigurationerna i '.gitconfig' -filen. Till min lättnadsgit kan skriva om miljövariablerna vi tillhandahåller när vi skapar ett kommitobjekt.
Först får jag listan över e-post-ID att bestämma vilka jag vill ändra:
Kommando: git log --all --pretty = format: '% an% d'–Detta skriver ut författarnamn (refnamn / grennamn)
För det andra springer jag igenom varje åtagande på varje gren och skriv om engagemangsobjektet med det nya e-post-id: t
Kommando:
git filtergren --env-filter '
om ['$ GIT_AUTHOR_NAME' = 'divya']
sedan
GIT_AUTHOR_EMAIL = 'divya@github.com'
vara
' -- --Allt
Borttappade och hittade filer
Antag att du har tappat bort en viss fil och att du inte kommer ihåg dess namn, men kan komma ihåg vissa ord i filen. I det här fallet kan du följa dessa steg-
Steg 1: Lista alla åtaganden som någonsin innehöll filbilden med det sökta mönstret
Kommando :git rev-list --all | xargs git grep -i 'tidsstämpel'
Steg 2 : Skapa en ny filial 'lost-found' från detta markerade commit-id
Syntax: git checkout -b förlorad-hittad d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Glömde vilken gren som har mitt engagemangs-id
Ibland, efter att du upptäckt ett buggy-commit-id kan du lika gärna vilja känna till alla grenar som har detta åtagande så att du kan fixa dem alla. Att kolla in varje filials historia är inte särskilt praktiskt i ett stort projekt med flera filialer.
Ett dåligt åtagande i min navigationsbyggnadsapplikation bröt en gång koden, det var då jag använde 'Git bisect' -kommando för att upptäcka det dåliga id-idet följt avkommando:git gren - innehålleratt lista grenarna med det dåliga åtagandet.
Så nu känner jag till alla grenar som fortfarande har ett dåligt engagemang, jag kan antingen återställa eller återställa denna ändringsuppsättning.
Ta bort ett engagemang från historiken
Ibland känner jag behovet av att bara utplåna ett åtagande från historien och inte lämna några spår av det. Jag skulle inte rekommendera dig att prova detta stunt på en delad filial utan bara på din lokala filial.
Syntax: git rebase -i
Kommando :git rebase -i 93859d8
I rebasredigeraren-> ersätt ”redigera” med ”släpp” för det markerade engagemangs-id: 69f4813
I vissa fall kan denna skrivning resultera i konflikter. Du måste lösa konflikter och sedan gå vidare.
Varning : Detta är ett farligt kommando eftersom det här skriver om historik och kan förlora data. En sådan gren skiljer sig från sin fjärrmotsvarare och måste pressas med--tvingaeller- force-with-leasealternativ.
Skjutit en fel gren till fjärrkontrollen
Här är vad jag vill göra - jag vill ta bort en avlägsen gren och sluta också spåra den från min lokala filial. 'git pushKommando när den används med--raderaalternativet tar bort fjärrgrenen Så det är så jag får den lokala kopian av det klonade projektet -
git-klon https://github.com/greets/myProj.git
cd myProj
En gång raderas fjärrgrenen andra i den delade repo måste uppdatera och uppdatera sina fjärrreferenser med--beskäraalternativ för att radera saknade objektreferenser:git hämta - beskär -v ursprung
I det här inlägget har jag nämnt några av de vanliga misstagen eller ändringarna som git kan hjälpa dig att fixa. Varje kod är unik och utvecklad på sitt sätt, så det finns också olika sätt att närma sig och åtgärda ett problem. Du kan alltid hänvisa till tjänstemannen git-dokumentation för att förstå hur olika git-kommandon skyddar din källkod och hur du använder kommandona på bästa möjliga sätt.
Nu när du har förstått de vanliga Git-misstagen, kolla in det här av Edureka, ett pålitligt inlärningsföretag online 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 detta 'vanliga Git-misstag' så återkommer vi till dig