Met de hausse van technologie, wordt het onvermijdelijk voor elke IT-persoon om tegelijkertijd aan meerdere gegevens te werken en uw gegevens evolueren voortdurend met de tijd. Het is ook essentieel om elke wijziging in de gegevens te volgen en bereid te zijn om eventuele ongewenste wijzigingen ongedaan te maken of ongedaan te maken wanneer dat nodig is.
Ik moet bekennen dat versiebeheer van mijn gegevens in Git me in staat stelt om meer experimenteel te zijn in mijn projectontwikkeling. Als ik het verpest, weet ik dat Git altijd een manier heeft om die versie van mijn project ongedaan te maken en / of terug te zetten naar de manier waarop het was voordat ik het verprutste. Elk laag is ontworpen om het mogelijk te maken dat de gegevenswijzigingen worden bekeken en gewijzigd en / of gecorrigeerd voordat de gegevens naar de volgende fase worden verplaatst. Dus de volgende zijn de fouten die in deze blog worden behandeld:
- Un-stage bestanden / mappen van Index
- Bewerk het laatste vastgelegde bericht
- Enkele wijzigingen in de laatste commit vergeten
- Gooi lokale wijzigingen weg
- Toegezegde persoonlijke gegevens aan de lokale repository
- De laatste commit vervangen door een nieuwe commit
- De verkeerde gegevens ingevoerd
- Ga terug naar mijn oude projectstatus
- Herstel een verwijderde lokale tak
- Maak wijzigingen in een vastlegging ongedaan
- Gaf een verkeerde naam aan mijn filiaal
- Wilt u de geschiedenislogboeken opnieuw rangschikken voordat u naar de afstandsbediening drukt
- Toegezegde niet-gerelateerde wijzigingen in één vastlegging
- Verander auteur-email in alle commits op alle branches
- Verloren en gevonden bestanden
- Vergeten welke branch mijn commit-id heeft
- Verwijder een commit uit de geschiedenis
- Een verkeerde tak naar de afstandsbediening geduwd
Un-stage bestanden / mappen van Index
Bij het toevoegen en / of wijzigen van bestanden heb je vaak de neiging om het standaardgedrag van het ‘git add’ commando te gebruiken, namelijk het toevoegen van alle bestanden en mappen aan de Index.Vaak heb je de behoefte om bepaalde bestanden ongedaan te maken of ze nog een laatste keer te wijzigen voordat je ze vastlegt.
Syntaxis: git reset
Door bestanden uit het indexgebied te verwijderen, krijgt u nog een kans om aan uw gegevens te werken voordat u zich vastlegt op een lokale opslagplaats.
Bewerk het laatste vastgelegde bericht
Opdracht: git commit --amend
U kunt het laatste vastleggingsbericht bewerken zonder een nieuw aan te maken. Om de vastleglogboeken weer te geven, heb ik een alias ‘hist’ ingesteld:
Opdracht: git config --global alias.hist 'log --pretty = format: '% C (geel)% h% Creset% ad | % C (groen)% s% Creset% C (rood)% d% Creset% C (blauw) [% an] '--graph --decorate --date = short'x
Wijzig het vastlegbericht niet dat al naar een externe repository is gepusht en met anderen is gedeeld, omdat dat de eerdere vastleggeschiedenis ongeldig zou maken en dus elk daarop gebaseerd werk kan worden beïnvloed.
Enkele wijzigingen in de laatste commit vergeten
Stel dat u bent vergeten enkele wijzigingen aan te brengen en uw momentopname al heeft vastgelegd, ook wilt u niet nog een keer vastleggen om uw fout te benadrukken.
Opdracht: git commit --amend
Ik heb benadrukt hoe de sha-1 id van het recente commit-object opnieuw is gemaakt en gewijzigd. Ik deed alsof ik een enkele commit had gedaan door beide wijzigingen in één te combineren.
Gooi lokale wijzigingen weg
Dus hier is een geval waarin ik het ‘README’ -bestand heb aangepast en geënsceneerd. Vervolgens heb ik hetzelfde bestand een tweede keer gewijzigd, maar ik realiseerde me dat ik de tweede wijziging niet wilde.
Laat me nu de hele wijziging niet handmatig ongedaan maken, ik kan gewoon de geënsceneerde versie van het bestand ophalen.
Syntaxis:
git checkout -–Lokale wijzigingen in een bestand
git checkout -–Lokale veranderingen in alle bestanden in de directory & verlegen & verlegen
Opdracht: git checkout - LEESMIJ
Dus ik heb mijn laatste wijzigingen aan het bestand weggegooid en de gefaseerde versie van het bestand geaccepteerd. Bij de volgende commit gaat alleen de gefaseerde versie van het bestand naar de lokale repository.
Toegezegde persoonlijke gegevens aan de lokale repository
Ik wil bepaalde gegevens uit de lokale repository verwijderen, maar de bestanden in de werkdirectory houden.
Syntaxis:
git reset --mixed HEAD ~
git reset --mixed
Opdracht: git reset --mixed HEAD ~ 1
HEAD ~ 1 geeft een commit aan net voor de recente commit waar de huidige branch HEAD naar verwijst.
Bestanden in de huidige momentopname zijn verwijderd uit zowel de lokale opslagplaats als het verzamelgebied. Voeg de volgende patronen toe aan het globale .gitignore-bestand om uit te sluiten dat ze door git worden gevolgd.
vim ~ / .gitignore_global
# wachtwoordbestanden #
*.voorbij gaan aan
*.sleutel
* .passwd
Hiermee wordt de commit met de momentopname van wachtwoordbestanden verwijderd en krijg je een schoon staginggebied. Mijn bestanden zijn nog steeds aanwezig in mijn werkmap maar zijn niet langer aanwezig in de lokale repository, en worden ook niet gepusht naar een externe repository.
Voorzichtigheid: Als je ze kwijtraakt, kan git ze niet voor je terughalen omdat het er niets van weet.
Vervang de laatste commit door een nieuwe commit
Syntaxis: git reset --soft [/ HEAD ~ n>]
De ‘–soft’ optie verwijdert gewoon de vastgelegde bestanden uit de lokale repository terwijl ze nog in de Index staan en je kunt ze opnieuw vastleggen na een beoordeling. is de sha-1 van de momentopname die u uit de lokale opslagplaats wilt verwijderen. waarbij n het aantal commits is voordat de HEAD commit
Opdracht :git reset --soft HEAD ~ 1
Wijzig bestanden en zet ze opnieuw op de planken
Opdracht: git commit -m 'Index.html en style.css toevoegen'
Je commit-geschiedenis blijkt nu te zijn:
De verkeerde gegevens ingevoerd
Syntaxis:
git reset --hard HEAD ~ n–Herstel het project naar ‘n’ commits vóór de laatste vastgelegde snapshot
git reset --hard–Reset het project naar de gegeven momentopname van de commit-ID
sql server basics voor beginners
Opdracht: git reset --hard HEAD ~ 1
De laatste commit en de corrupte bestanden worden verwijderd uit de lokale repository, het staging-gebied en de werkdirectory.
Voorzichtigheid: Het is een gevaarlijke opdracht omdat je uiteindelijk bestanden kwijtraakt in de werkmap. Niet aanbevolen voor een op afstand gedeelde repository.
Ga terug naar mijn oude projectstatus
U kunt naar een oudere staat van uw project in de geschiedenis van de tijd verwijzen. Als je de laatste versie verknoeit of verbeteringen in oudere code nodig hebt, wil je misschien een andere branch uit die oude project-snapshot maken om je huidige werk niet te hinderen. Laten we eens kijken hoe:
een. Maak een lijst van de projectgeschiedenis en beslis over de oudere commit-id, commando:ga hist b. Maak een andere branch uit de commit-id:
git checkout -b old-state e7aa9a5
c. Ga door met werken aan de code en later merge / rebase met de ‘master’ branch.
Herstel een verwijderde lokale tak
Het is mogelijk om het verloren werk op een referentietak opnieuw te genereren. Stel, ik heb de branch ‘old_code’ verwijderd zonder te fuseren met de hoofdtak en het werk verloren. En nee, ik heb de branch ook niet naar een externe repository gepusht, wat dan? Nou git tracks en houd een logboek bij van alle wijzigingen die zijn aangebracht op elke referentie, laten we de mijne bekijken:ga reflog
Dus, HEAD @ {2} is de aanwijzer toen ik naar de ‘old_code’ branch ging, laten we dat herstellen:
Syntaxis:git checkout -b
Opdracht:git checkout -b old_code HEAD @ {2}
Je moet nu in de 'old_code' branch zijn met je laatste werk op het moment van creatie. Bovendien was de 'reflog' pointer op HEAD @ {1} de recente commit die gemaakt is op de 'old_code' branch. commit voer gewoon het commando uit als:git reset --hard HEAD @ {1}.Dit herstelt ook de gewijzigde bestanden in de werkdirectory.
Als je in detail wilt weten hoe dit commando werkt en hoe je de ‘reflog’ -items kunt beheren, kun je net zo goed mijn eerdere bericht lezen ophet herstellen van de verwijderde branch uit git reflog.
Maak wijzigingen in een vastlegging ongedaan
Gaanterugdraaienwordt gebruikt om enkele nieuwe commits op te nemen om het effect van eerdere commits ongedaan te maken.
Syntaxis: git revert
Vanuit mijn commits-logs wil ik de wijziging die is aangebracht in de gemarkeerde commit-id ongedaan maken:
Opdracht: git terugzetten 827bc0d
Het is beter dat je de gedeelde commits niet '–hard' reset, maar in plaats daarvan 'git revert' om de historie te behouden, zodat het voor iedereen gemakkelijker wordt om de historielogboeken op te sporen om erachter te komen wat er is teruggedraaid, door wie en waarom?
Je kunt dezelfde logica gebruiken om de commits te verwijzen met betrekking tot de HEAD-pointer in plaats van de commit-id op te geven, zoals in HEAD ~ 3 of HEAD ~ 4 enzovoort.
Gaf een verkeerde naam aan mijn filiaal
U kunt de naam van een lokaal filiaal wijzigen. Het komt zo vaak voor dat je je branch zou willen hernoemen op basis van het probleem waar je aan werkt, zonder de moeite te hoeven doen om al je werk van de ene locatie naar de andere te migreren. U kunt bijvoorbeeld op dezelfde branch of een andere branch zitten en toch de gewenste branch hernoemen zoals hieronder getoond:
Syntaxis: git branch -m
Opdracht: git branch -m old_code old_ # 4920
Zoals je je misschien afvraagt, houdt git deze hernoeming bij? Ja, het verwijst naar uw ‘reflog’-vermeldingen, hier is de mijne:
Het hernoemen van een branch heeft geen invloed op de remote tracking branch. We zullen in de remote sectie zien hoe je een branch op de remote repository vervangt
Herschik geschiedenislogboeken voordat u naar de afstandsbediening drukt
Ik zou graag willen dat ik bepaalde commits eerder had gedaan dan andere en dat ik sommige commits helemaal niet zou hebben gedaan. Herschik en bewerk de oude commits interactief om de code effectief op te lossen of te verbeteren
Syntaxis: git rebase -i
Opdracht: git rebase -i fb0a90e–Begin met het rebasen van de commits die gemaakt zijn na de commit-id fb0a90e
Bezoek het git rebase documentatie om te begrijpen hoe een ‘–interactieve of -i’ rebase verschilt van een reguliere rebase.
Toegezegde niet-gerelateerde wijzigingen in één vastlegging
In dit geval moet je een oude begraven commit splitsen in meerdere logische commits.
Syntaxis: git rebase -i
Opdracht: git rebase -i fb0a90e
In de rebase-editor moet je de e7aa9a5 commit-id kiezen en deze wijzigen in ‘bewerken’ in plaats van ‘kiezen’.
Je zou nu in de projectversie van commit id-e7aa9a5 zijn. Reset eerst de vastleghistorie en het staging-gebied naar het vorige vastleggingscommando:git reset HEAD ~ 1
Ten tweede, bewerk + stage + leg de bestanden afzonderlijk vast
Opdrachten:
git add code && git commit -m 'Initiële codes toevoegen'
git add newcode && git commit -m 'Nieuwe code toevoegen'
Ten derde, ga door met de rebase en eindig.
Opdracht :git rebase --continue
Ten vierde, bekijk de geschiedenis met aanvullende commits.
Opdracht: ga hist
Verander auteur-email in alle commits op alle branches
Ik ben al een hele tijd bezig met versiebeheer en het committeren van mijn projectbestanden in git, maar tot nu toe viel het me nooit op dat mijn e-mail-id was gecompromitteerd in mijn vastleggeschiedenislogboeken die zelfs op externe opslagplaatsen zijn gepubliceerd. Nou, dit kan iedereen overkomen als je de configuraties voor het eerst instelt in het '.gitconfig' bestand. Tot mijn opluchting kan git herschrijven de omgevingsvariabelen die we bieden bij het maken van een commit-object.
Eerst krijg ik de lijst met e-mail-ID's om te beslissen welke ik wil wijzigen:
Opdracht: git log --all --pretty = format: '% an% d'–Dit drukt de naam van de auteur (refname / branch-name) af
Ten tweede ren ik erdoorheen elke commit op elke branch en herschrijf het commit-object met het nieuwe e-mail-ID
Opdracht:
git filter-branch --env-filter '
if ['$ GIT_AUTHOR_NAME' = 'divya']
vervolgens
GIT_AUTHOR_EMAIL = 'divya@github.com'
worden
' -- --alle
Verloren en gevonden bestanden
Stel dat u een bepaald bestand bent kwijtgeraakt en u de naam niet meer weet, maar u kunt zich bepaalde woorden in het bestand herinneren. In dit geval kunt u deze stappen volgen:
Stap 1: Maak een lijst van alle commits die ooit de momentopname van het bestand met het gezochte patroon bevatten
Opdracht :git rev-list --all | xargs git grep -i 'timestamp'
Stap 2 : Maak een nieuwe branch ‘verloren gevonden’ van deze gemarkeerde commit-id
Syntaxis: git checkout -b verloren gevonden d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Vergeten welke branch mijn commit-id heeft
Soms, nadat je een commit-id met fouten hebt gedetecteerd, kun je net zo goed alle branches willen weten die deze commit op zich hebben, zodat je ze allemaal kunt repareren. Het achterhalen van de geschiedenis van elke branche is niet erg praktisch in een groot project met meerdere branches.
Een slechte commit in mijn applicatie voor het bouwen van navigatie brak eens de code, dat is toen ik de ‘Git bisect’ commando om de commit id te detecteren die slecht was gevolgd door deopdracht:git branch - bevatom de branches met die slechte commit op te sommen.
Dus nu ik alle branches ken die nog steeds de slechte commit hebben, zou ik deze wijzigingenset kunnen terugdraaien of resetten.
Verwijder een commit uit de geschiedenis
Soms heb ik de behoefte om een commit gewoon uit de geschiedenis te wissen en er geen spoor van achter te laten. Ik zou je niet aanraden om deze stunt op een gedeelde branche uit te proberen, maar alleen op je lokale branch.
Syntaxis: git rebase -i
Opdracht :git rebase -i 93859d8
In de rebase-editor-> vervang ‘edit’ door ‘drop’ voor de gemarkeerde commit-id: 69f4813
In sommige gevallen kan dit herschrijven tot conflicten leiden. U moet conflicten oplossen en vervolgens verder gaan.
Waarschuwing : Dit is een gevaarlijke opdracht omdat hierdoor de geschiedenis opnieuw wordt geschreven en er mogelijk gegevens verloren gaan. Zo'n vertakking verschilt van zijn externe tegenhanger en zal moeten worden gepusht met de--dwingenof--force-with-leasekeuze.
wat is hashset in java
Een verkeerde tak naar de afstandsbediening geduwd
Nu, hier is wat ik wil doen: ik wil een afgelegen filiaal en stop ook met het volgen van mijn lokale filiaal. 'git push‘Commando bij gebruik met de--verwijderenoptie verwijdert de remote branch Dus dit is hoe ik de lokale kopie van het gekloonde project krijg -
git clone https://github.com/greets/myProj.git
cd myProj
Zodra de remote branch is verwijderd, moeten anderen op de gedeelde repo hun remote referenties vernieuwen en bijwerken met de--gedroogde pruimoptie om de ontbrekende objectreferenties te verwijderen:git fetch --prune -v oorsprong
In dit bericht heb ik enkele van de veelvoorkomende fouten of wijzigingen genoemd die git je kan helpen oplossen. Elke code is uniek en op zijn manier ontwikkeld, dus er zijn ook verschillende manieren om een probleem te benaderen en op te lossen. U kunt altijd verwijzen naar de ambtenaar git documentatie om te begrijpen hoe verschillende git-commando's je broncode beschermen en hoe je de commando's op de best mogelijke manier kunt gebruiken.
Nu je de veelvoorkomende Git-fouten hebt begrepen, moet je dit eens bekijken door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka DevOps Certification Training-cursus helpt leerlingen te begrijpen wat DevOps is en expertise op te doen in verschillende DevOps-processen en -tools zoals Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack en GIT voor het automatiseren van meerdere stappen in SDLC.
Heeft u een vraag voor ons? Vermeld het alsjeblieft in het commentaargedeelte van deze 'veelvoorkomende Git-fouten' en we nemen contact met je op