-
1. Aan de slag
- 1.1 Over versiebeheer
- 1.2 Een kort historisch overzicht van Git
- 1.3 Wat is Git?
- 1.4 De commando-regel
- 1.5 Git installeren
- 1.6 Git klaarmaken voor eerste gebruik
- 1.7 Hulp krijgen
- 1.8 Samenvatting
-
2. Git Basics
-
3. Branchen in Git
- 3.1 Branches in vogelvlucht
- 3.2 Eenvoudig branchen en mergen
- 3.3 Branch-beheer
- 3.4 Branch workflows
- 3.5 Branches op afstand (Remote branches)
- 3.6 Rebasen
- 3.7 Samenvatting
-
4. Git op de server
- 4.1 De protocollen
- 4.2 Git op een server krijgen
- 4.3 Je publieke SSH sleutel genereren
- 4.4 De server opzetten
- 4.5 Git Daemon
- 4.6 Slimme HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Hosting oplossingen van derden
- 4.10 Samenvatting
-
5. Gedistribueerd Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisie Selectie
- 7.2 Interactief stagen
- 7.3 Stashen en opschonen
- 7.4 Je werk tekenen
- 7.5 Zoeken
- 7.6 Geschiedenis herschrijven
- 7.7 Reset ontrafeld
- 7.8 Mergen voor gevorderden
- 7.9 Rerere
- 7.10 Debuggen met Git
- 7.11 Submodules
- 7.12 Bundelen
- 7.13 Vervangen
- 7.14 Het opslaan van inloggegevens
- 7.15 Samenvatting
-
8. Git aanpassen
- 8.1 Git configuratie
- 8.2 Git attributen
- 8.3 Git Hooks
- 8.4 Een voorbeeld van Git-afgedwongen beleid
- 8.5 Samenvatting
-
9. Git en andere systemen
- 9.1 Git als een client
- 9.2 Migreren naar Git
- 9.3 Samenvatting
-
10. Git Binnenwerk
- 10.1 Binnenwerk en koetswerk (plumbing and porcelain)
- 10.2 Git objecten
- 10.3 Git Referenties
- 10.4 Packfiles
- 10.5 De Refspec
- 10.6 Uitwisseling protocollen
- 10.7 Onderhoud en gegevensherstel
- 10.8 Omgevingsvariabelen
- 10.9 Samenvatting
-
A1. Bijlage A: Git in andere omgevingen
- A1.1 Grafische interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Samenvatting
-
A2. Bijlage B: Git in je applicaties inbouwen
- A2.1 Commando-regel Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bijlage C: Git Commando’s
- A3.1 Setup en configuratie
- A3.2 Projecten ophalen en maken
- A3.3 Basic Snapshotten
- A3.4 Branchen en mergen
- A3.5 Projecten delen en bijwerken
- A3.6 Inspectie en vergelijking
- A3.7 Debuggen
- A3.8 Patchen
- A3.9 Email
- A3.10 Externe systemen
- A3.11 Beheer
- A3.12 Binnenwerk commando’s (plumbing commando’s)
2.4 Git Basics - Dingen ongedaan maken
Dingen ongedaan maken
Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis-tools laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Maar pas op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige situaties in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
Een van de veel voorkomende acties die ongedaan gemaakt moeten worden vindt plaats als je te vroeg commit en misschien vergeten bent een aantal bestanden toe te voegen, of je verknalt je commit boodschap.
Als je opnieuw wilt committen, de aanvullende wijzigingen maken die je was vergeten, deze stagen en weer committen, dan kun je commit met de --amend
optie uitvoeren:
$ git commit --amend
Dit commando neemt je staging area en gebruikt dit voor de commit. Als je geen veranderingen sinds je laatste commit hebt gedaan (bijvoorbeeld, je voert dit commando meteen na je laatste commit uit), dan zal je snapshot er precies hetzelfde uitzien en zal je commit boodschap het enige zijn dat je verandert.
Dezelfde commit-boodschap editor start op, maar deze bevat meteen de boodschap van je vorige commit. Je kunt de boodschap net als andere keren aanpassen, maar het overschrijft je vorige commit.
Bijvoorbeeld, als je commit en je dan realiseert dat je vergeten bent de veranderingen in een bestand dat je wilde toevoegen in deze commit te stagen, dan kun je zoiets als dit doen:
$ git commit -m 'initial commit'
$ git add vergeten_bestand
$ git commit --amend
Na deze drie commando’s eindig je met één commit; de tweede commit vervangt de resultaten van de eerste.
Noot
|
Het is belangrijk te beseffen dat als je de laatste commit amendeert, je deze niet zo zeer repareert als wel in z’n geheel vervangt met een nieuwe, verbeterde commit die de oude commit uit de weg duwt en de nieuwe daarvoor in de plaats zet. Effectief is het alsof de vorige commit nooit heeft plaatsgevonden, en het zal niet in je repository geschiedenis te zien zijn. De overduidelijke waarde van amenderende commits is om kleine verbeteringen aan te brengen aan je laatste commit, zonder je repository geschiedenis te vervuilen met commit berichten van het soort “Oeps, weer een file vergeten toe te voegen” of “Verdraaid, een typefout in de laatste commit gecorrigeerd”. |
Een gestaged bestand unstagen
De volgende twee paragrafen laten zien hoe je de staging area en veranderingen in je werkdirectories aanpakt.
Het prettige hier is dat het commando dat je gebruikt om de status van die gebieden te bepalen, je er ook aan herinnert hoe je de veranderingen eraan weer ongedaan kunt maken.
Bijvoorbeeld, stel dat je twee bestanden gewijzigd hebt en je wilt ze committen als twee aparte veranderingen, maar je typt per ongeluk git add *
en staget ze allebei.
Hoe kun je één van de twee nu unstagen?
Het git status
commando herinnert je eraan:
$ git add *
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
modified: CONTRIBUTING.md
Direct onder de “Changes to be committed” tekst, staat dat je git reset HEAD <file>...
moet gebruiken om te unstagen.
Laten we dat advies volgen om het CONTRIBUTING.md
bestand te unstagen:
$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Het commando is een beetje vreemd, maar het werkt.
Het CONTRIBUTING.md
bestand is gewijzigd maar weer unstaged.
Noot
|
Hoewel |
Voor nu is deze toverspreuk alles wat je hoeft te weten van het git reset
commando.
We zullen nog veel meer details behandelen over wat reset
doet en hoe dit onder te knie te krijgen zodat je werkelijke heel interessante dingen kunt doen in Reset ontrafeld.
Een gewijzigd bestand weer ongewijzigd maken
Wat als je je bedenkt dat je de wijzigingen aan het CONTRIBUTING.md
bestand niet wilt behouden?
Hoe kun je dit makkelijk ongedaan maken; terugbrengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gekloond, of hoe je het ook in je werkdirectory gekregen hebt)?
Gelukkig vertelt git status
je ook hoe je dat moet doen.
In de laatste voorbeeld-uitvoer, ziet het unstaged gebied er zo uit:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Het vertelt je behoorlijk expliciet hoe je je veranderingen moet weggooien. Laten we eens doen wat er staat:
$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Je kunt zien dat de veranderingen teruggedraaid zijn.
Belangrijk
|
Het is belangrijk om te beseffen dat |
Als je het voor nu alleen maar even uit de weg wilt hebben, gebruik dan branching of stashing wat we behandelen in Branchen in Git; dit zijn vaak de betere opties.
Onthoud, alles dat in Git gecommit is kan bijna altijd weer hersteld worden.
Zelfs commits die op reeds verwijderde branches gedaan zijn, of commits die zijn overschreven door een --amend
commit, kunnen weer hersteld worden (zie Gegevensherstel voor data herstel).
Maar, alles wat je verliest dat nog nooit was gecommit is waarschijnlijk voorgoed verloren.