Share
Het hele punt van het onderhouden van "veilige" kopieën van een softwareproject is gemoedsrust: mocht je project plotseling breken, dan weet je dat je gemakkelijk toegang hebt tot een functionele versie, en kun je precies vaststellen waar het probleem zit werd geïntroduceerd. Daartoe is het opnemen van commits nutteloos zonder de mogelijkheid om wijzigingen ongedaan te maken. Omdat Git zoveel componenten heeft, kan 'ongedaan maken' echter veel verschillende betekenissen hebben. U kunt bijvoorbeeld:
Om de zaken nog verder te compliceren, zijn er meerdere manieren om een commit ongedaan te maken. Je kan of:
Git heeft een speciale tool voor elk van deze situaties. Laten we beginnen met de werkdirectory.
De tijdsperiode onmiddellijk na het opslaan van een veilige kopie van een project is er een van grote innovatie. Bekrachtigd door de kennis die u vrij bent om te doen iets je wilt zonder de codebasis te beschadigen, je kunt naar hartelust experimenteren. Dit zorgeloze experiment neemt echter vaak een verkeerde afslag en leidt tot een werkmap met een hoop off-topic-code. Wanneer u dit punt bereikt, wilt u waarschijnlijk de volgende opdrachten uitvoeren:
git reset --hard HEAD git clean -f
Deze configuratie van git reset zorgt ervoor dat de werkdirectory en de fase overeenkomen met de bestanden in de meest recente commit (ook wel genoemd HOOFD), waardoor alle niet-gecommiteerde wijzigingen in bijgehouden bestanden. Verwijderen untracked bestanden, moet u de git schoon commando. Git is heel voorzichtig met het verwijderen van code, dus u moet ook de -f optie om het verwijderen van deze bestanden te forceren.
Het is ook mogelijk om individuele bestanden te targeten. Met de volgende opdracht zal een enkel bestand in de werkmap overeenkomen met de versie in de meest recente commit.
git uitchecken HEAD
Deze opdracht verandert de projectgeschiedenis helemaal niet, dus u kunt deze veilig vervangen HOOFD met een commit-ID, branch of tag om het bestand te laten overeenkomen met de versie in die commit. Maar doe niet probeer dit met git reset, zoals zullen verander je geschiedenis (uitgelegd in Commits ongedaan maken).
Accentsconagua
git uitchecken Tijdens het configureren van je volgende commit, voeg je af en toe een extra bestand toe aan het podium. De volgende aanroep van git reset zal het podium unstage:
GIT reset HEAD
Het weglaten van de --hard flag vertelt Git om de werkmap alleen te verlaten (in tegenstelling tot git reset --hard HEAD, waarbij elk bestand in zowel de werkdirectory als de fase opnieuw wordt ingesteld). De gefaseerde versie van het bestand komt overeen HOOFD, en de werkdirectory behoudt de gewijzigde versie. Zoals je zou verwachten, resulteert dit in een ongestage modificatie in jouw git status uitgang.
git reset Er zijn twee manieren om een commit ongedaan te maken met Git: dat kan ook reset door het simpelweg uit de projectgeschiedenis te verwijderen, of u kunt het terugkeren het door het genereren van een nieuwe commit die de wijzigingen die in het origineel zijn aangebracht, kwijtraakt. Ongedaan maken door het introduceren van een andere commit lijkt misschien overdreven, maar het herschrijven van de geschiedenis door commits volledig te verwijderen kan ernstige gevolgen hebben in multi-user workflows.
De altijd veelzijdige git reset kan ook worden gebruikt om verhuizing de HOOFD referentie.
GIT reset HEAD ~ 1
De HEAD ~ 1 syntaxisparameter geeft de commit aan die onmiddellijk daarvoor plaatsvond HOOFD (hetzelfde, HEAD ~ 2 verwijst naar de tweede commit eerder HOOFD). Door de HOOFD referentie achterwaarts verwijdert, verwijdert u effectief de meest recente commit uit de geschiedenis van het project.
HOOFD naar HEAD ~ 1 met git reset Dit is een eenvoudige manier om een aantal commits te verwijderen die van het onderwerp zijn afgeweken, maar het vertoont een serieus samenwerkingsprobleem. Als andere ontwikkelaars begonnen te bouwen bovenop de commit die we hadden verwijderd, hoe zouden ze dan synchroniseren met onze repository? Ze zouden ons moeten vragen naar de ID van de vervangende commit, deze handmatig moeten opzoeken in je repository, al hun wijzigingen moeten verplaatsen naar die commit, het oplossen van samenvoegingsconflicten moeten oplossen en hun 'nieuwe' wijzigingen moeten delen met iedereen nog een keer. Stel je eens voor wat er zou gebeuren in een open-sourceproject met honderden bijdragers ...
Het punt is, voer openbare commits niet opnieuw in, maar voel je vrij om privé-e-mails te verwijderen die je nog niet met iemand hebt gedeeld. We zullen dit concept later in deze sessie opnieuw bekijken.
Om de problemen te verhelpen die werden geïntroduceerd door publieke commits opnieuw in te stellen, hebben Git-ontwikkelaars een andere manier bedacht om commits ongedaan te maken: de revert. In plaats van het wijzigen van bestaande commits, voegt het terugzetten een a toe nieuwe commit die het probleem commit ongedaan maakt:
Ga terug
Dit neemt de wijzigingen in de opgegeven commit aan, berekent hoe ze ongedaan gemaakt kunnen worden en creëert een nieuwe commit met de resulterende changeset. Voor Git en voor andere gebruikers ziet de Revert-commit eruit en gedraagt zich als elke andere commit - het gebeurt gewoon om de wijzigingen ongedaan te maken die zijn geïntroduceerd door een eerdere commit.
Dit is de ideale manier om wijzigingen ongedaan te maken die al zijn vastgelegd in een openbare repository.
Naast het volledig ongedaan maken van commits, kunt u ook wijzigen de meest recente commit door de veranderingen zoals gebruikelijk te stagen en vervolgens uit te voeren:
git commit --amend
Deze vervangt de vorige commit in plaats van een nieuwe te maken, wat erg handig is als je bent vergeten een of twee bestanden toe te voegen. Voor uw gemak is de commit-editor voorzien van het bericht van de oude commit. Nogmaals, dat moet je doen doe voorzichtig bij gebruik van de --wijzigen vlag, want het herschrijft de geschiedenis veel als git reset.
Deze les vertegenwoordigt een hoofdstuk van Git Kortbij, een gratis eBoek van het team van Syncfusion.
