De commit-geschiedenis van Git is ontworpen om onveranderlijk te zijn (voor de voor het grootste deel) en houd elke wijziging in uw project bij, zodat u nooit werk verliest. Soms is het echter nodig om de Git-geschiedenis te herschrijven, dus Git biedt een paar hulpmiddelen voor het bewerken van bestaande commits.
Nieuwe wijzigingen aan commits toevoegen< /h2>
Het meest voorkomende gebruik hiervoor is wanneer je een commit-bericht maakt en dan, voordat je naar je afstandsbediening drukt, je realiseert dat je een fout hebt gemaakt en een kleine wijziging moet aanbrengen. Je kunt natuurlijk gewoon een tweede commit maken, maar dat is niet nodig, en laat ook al je collega's je domme fout zien wanneer je uiteindelijk naar de afstandsbediening pusht.
Als je gewoon toevoegt wijzigingen, kunt u git commit –amend gebruiken. Dit wijzigt de meest recente commit en voegt de aanvullende wijzigingen die je hebt gestaged samen.
Eerst moet je je wijzigingen stagen:
git add .
En dan wijzigen:
git commit –amend –no-edit
De –no-edit-vlag zorgt ervoor dat de opdracht het commit-bericht niet wijzigt. Als u de nieuwe wijzigingen in een nieuw bericht wilt verduidelijken, laat deze vlag dan weg en u wordt gevraagd om het nieuwe vastleggingsbericht.
Onder de motorkap maakt het wijzigingscommando een nieuwe commit met de extra wijzigingen en vervangt dan de broncommit in de Git-geschiedenis volledig. De oude commit is nog steeds toegankelijk via git reflog (meer daarover hieronder), maar in de toekomst is de nieuwe commit de enige die bestaat. Wanneer je naar een externe repo pusht, is er geen manier om te weten dat de commit is gewijzigd, het is een puur lokale wijziging.
Advertentie
Hierdoor zul je niet commits wilt wijzigen die al zijn gepusht, omdat je veel problemen zult tegenkomen en met geweld naar de afstandsbediening moet pushen, wat voor niemand goed is.
Just The Git Commit Message wijzigen
Als je geen wijzigingen hoeft aan te brengen en gewoon een typfout wilt corrigeren, kun je ook wijzigen zonder wijzigingen uitvoeren:
git commit –amend -m “an updated commit message”
Unstaging Changes From Commits
Het wijzigingscommando van Git werkt alleen als je& #8217;zijn strikt wijzigingen aan het toevoegen. Als we zeggen “toegevoegd,” we bedoelen niet alleen nieuwe regels code; het veranderen van een regel code is ook het toevoegen van wijzigingen. Het verwijderen van een regel code, of een heel bestand, is ook een wijziging die wordt toegevoegd, ook al verwijdert het gegevens uit het project wanneer die wijziging wordt toegepast.
Er zijn echter ook gevallen waarin u wijzigingen daadwerkelijk uit vastleggingen wilt verwijderen. Stel bijvoorbeeld dat je het volgende hebt uitgevoerd:
git add . git commit
En voegde elke wijziging in je repo toe aan de gefaseerde wijzigingen, en legde het vast, voordat je je realiseerde, “oh crap! Het was niet mijn bedoeling om dat ene bestand te committen!” In dit geval moet u alle wijzigingen terugsturen naar staging en vervolgens handmatig de bestanden destageren die u niet wilt pushen.
De oplossing is om een reset uit te voeren, de commit te verwijderen en de wijzigingen terug te sturen. Er zijn een paar soorten resets, maar ze houden allemaal in dat je commits uit de Git-geschiedenis neemt en ze terugstuurt naar ofwel staging, de lokale map of rechtstreeks naar de prullenbak.
Advertentie
In dit geval is een zachte reset wat u wilt, waardoor alle wijzigingen worden teruggestuurd te ensceneren. Je kunt de volgende afkorting gebruiken om te resetten naar de commit achter de HEAD, anders moet je de referentie uit git reflog halen:
git reset –soft HEAD~
Vervolgens moet je het bestand verwijderen dat je niet wilt vastleggen. De manier om dit te doen is eigenlijk ook een reset, in dit geval een gemengde reset op een specifiek bestand:
git reset –mixed bestandsnaam
Dit werkt omdat het resetten van dit ene bestand de wijzigingen uit de staging verwijdert, en het wordt niet vastgelegd als je de commit opnieuw doet.
Je kunt ook een gemengde reset uitvoeren op de hele repo en git alle bestanden toevoegen behalve degene die je niet wilt. Dit is gemakkelijker te doen als je een GUI Git-client gebruikt.
Moet je een commit ongedaan maken/verwijderen? Gebruik Terugzetten
Het terugzetten van een commit is de gemakkelijkste manier om wijzigingen te verwijderen. Kortom, het neemt alle wijzigingen van de doel-commit en past het tegenovergestelde ervan toe. Als je een bestand hebt gemaakt, wordt het verwijderd. Als je een regel code hebt verwijderd, wordt die code weer toegevoegd. Het is de door Git goedgekeurde manier om te “verwijderen” of “ongedaan maken” een commit, omdat het origineel nog steeds in de git-geschiedenis wordt bewaard.
Om het te gebruiken, voer je git log uit om de commits te bekijken:
git log
Kopieer de referentie-ID en keer de commit terug:
git revert 62ff517cc7c358eaf0bffdebbbe1b38dea92ba0f
Als je net vastloopt in vim, druk op Q, en voer misschien git config –global core.editor “nano” uit.
Gebruik rebasen voor alles wat ingewikkelder is
Rebasen is in wezen een methode om commits in je repository te verplaatsen. In plaats van samen te voegen, herschrijft rebase de git-geschiedenis om individuele commits naar een nieuwe locatie te verplaatsen. De originele commits blijven hangen en worden verwijderd uit de officiële Git-geschiedenis, hoewel ze nog steeds aanwezig zijn in git reflog.
Advertentie
We zullen hier niet ingaan op de exacte details ervan, maar als je geïnteresseerd bent in hoe het werkt, kun je onze handleiding voor het gebruik van git rebase lezen.
Wat als je terug wilt gaan?
Gelukkig houdt Git elke wijziging bij, zelfs als je de regels overtreedt en de geschiedenis herschrijft.
Elke keer dat je branch-tip om welke reden dan ook wordt bijgewerkt, slaat Git de status van de directory-inhoud vóór de update op in het Referentielogboek of reflog. Je kunt de log bekijken met git reflog:
git reflog
Veel hiervan zullen daadwerkelijke commits zijn, maar het omvat ook andere wijzigingen. Als je terug moet naar een individuele wijziging, kun je een harde reset uitvoeren:
git reset –hard fdb9db9
Dit biedt een mooi vangnet, maar je moet gewaarschuwd worden dat reflog alleen wijzigingen bijhoudt die daadwerkelijk toegewijd, niet alleen geënsceneerd, en het volgt alleen bewegingen van de vertakkingspunt. Bovendien bewaart reflog inzendingen slechts 90 dagen. Daarna kun je alleen terugzetten naar de daadwerkelijke commits.