Git-tutorial: de basiscommando’s (add, commit, push, pull)

Vijf commando’s volstaan voor het dagelijkse werk: status, add, commit, push en pull. Dit hoofdstuk neemt ze een voor een door en behandelt daarna wat geen enkele tutorial mag overslaan: hoe je terugkomt op je stappen als je de fout in bent gegaan.

Eén voorwaarde vooraf: je identiteit moet ingesteld zijn, anders weigert Git je eerste commit. Is dat nog niet gebeurd, ga dan terug naar het installatiehoofdstuk.

De drie zones van Git

Alles wordt eenvoudiger zodra je doorhebt dat je bestanden zich altijd in een van drie zones bevinden.

• De working directory: je bestanden zoals je ze in de verkenner ziet.
• De index, ook wel staging area: de lijst van wat er in de volgende commit terechtkomt. git add zet je wijzigingen daarin.
• De repository: de geschiedenis van de commits, dat wat git commit voedt.

Die tussenzone is in het begin verwarrend, maar juist zij laat je drie van de vijf wijzigingen vastleggen en de twee andere bewaren voor een aparte commit.

git status, het commando dat je de hele tijd typt

Het vertelt je waar je staat, en de meldingen bevatten bijna altijd het commando dat daarna aan de beurt is. Maak er een gewoonte van om het voor en na elke handeling te draaien.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

De korte versie past op één regel per bestand en wordt snel een reflex:

git status --short

?? .env
?? app.js
?? node_modules/

?? staat voor een bestand dat Git nog niet volgt, A voor een bestand dat aan de index is toegevoegd, M voor een gewijzigd bestand.

.gitignore: wat er nooit in mag komen

Nog voor je eerste git add zet je opzij wat niets in een repository te zoeken heeft: herinstalleerbare dependencies, configuratiebestanden met secrets erin, bestanden die je systeem of je editor genereert.

Maak een bestand .gitignore in de root van het project:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Draai git status opnieuw: de genegeerde bestanden staan niet meer in de lijst.

?? .gitignore
?? app.js

De .gitignore zelf staat wél onder versiebeheer: hij hoort bij het project en moet met het team gedeeld worden.

Let op een valkuil: .gitignore heeft geen enkel effect op een bestand dat al gevolgd wordt. Heb je een .env gecommit voor je eraan dacht, dan moet je hem expliciet uit de index halen:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

De optie --cached is cruciaal: die haalt het bestand uit de index zonder het van je schijf te verwijderen.

En beschouw de secrets die erin stonden als gelekt: ze blijven leesbaar in de geschiedenis. Vervang ze.

git add: de commit voorbereiden

git add app.js          # één bestand
git add src/            # een hele map
git add .               # alles wat is gewijzigd onder de huidige map
git add -p              # stuk voor stuk kiezen, interactief

git add -p verdient het om vroeg uit te proberen. Git toont je elk blok wijzigingen en vraagt of het in de commit hoort. Het is de eenvoudigste manier om commits te maken die één ding vertellen.

git commit: vastleggen

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Staat er niets in de index, dan maakt Git niets aan en zegt het je:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Over commitberichten is maar één regel het onthouden waard: schrijf wat de commit doet, niet waar je aan hebt gezeten. “Corrigeert de btw-berekening op bestellingen buiten de EU” is beter dan “wijziging factuur.php”. Je schrijft voor jezelf over zes maanden.

De afkorting -am combineert add en commit, maar alleen voor bestanden die al gevolgd worden:

git commit -am "Corrige le libellé du bouton"

De geschiedenis lezen

git log                                  # volledig
git log --oneline                        # één regel per commit
git log --oneline --graph --decorate     # met de vorm van de branches
git log -p app.js                        # de geschiedenis van één bestand, met de diffs

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD geeft aan waar je je in de geschiedenis bevindt. De pijl laat zien dat HEAD de branch main volgt.

Je wijzigingen bekijken voor je commit

Twee commando’s die vaak door elkaar worden gehaald en naar twee verschillende zones kijken.

git diff            # wat gewijzigd is maar nog niet in de index staat
git diff --staged   # wat in de index staat en meegaat in de volgende commit

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Na een git add app.js kantelt dezelfde wijziging: git diff geeft niets meer terug en git diff --staged toont het blok. Dat is de beste manier om de index voor je te zien.

git push en git pull: uitwisselen met de server

git push        # de lokale commits versturen
git pull        # die van de anderen ophalen en integreren

Deze twee korte vormen werken alleen als de branch een koppeling met de server heeft, aangelegd door de -u uit het vorige hoofdstuk. Die koppeling controleer je zo:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

De branch main volgt origin/main, de branch feature/panier volgt voorlopig niets.

Heeft iemand gepusht terwijl jij aan het werk was, dan wordt je push geweigerd. Wat je dan doet en waarom, staat in het hoofdstuk over branches.

Een blunder ongedaan maken

Dit is het deel waar beginners het vaakst naar zoeken en dat hun het minst wordt uitgelegd. De goede reflex is eerst één vraag beantwoorden: staat wat ik ongedaan wil maken al op de server?

Het bestand is gewijzigd, ik wil terug naar de laatste commit

git restore app.js       # één bestand
git restore .            # de hele working directory

Let op: dit commando vernietigt je wijzigingen zonder vangnet. Ze zijn nergens vastgelegd, dus Git kan ze niet terughalen.

Ik heb te snel git add gedaan

git restore --staged app.js

Het bestand gaat uit de index, je wijzigingen blijven intact in de working directory.

Deze twee commando’s zijn het moderne equivalent van git checkout -- fichier en git reset HEAD fichier. git restore bestaat sinds Git 2.23 en zegt duidelijk wat het doet, terwijl checkout en reset elk drie verschillende dingen doen afhankelijk van de opties.

Het bericht van mijn laatste commit deugt niet

git commit --amend -m "Le bon message"

Hetzelfde commando dient om een vergeten bestand toe te voegen: doe je git add en draai dan opnieuw git commit --amend. Gebruik het alleen op een commit die nog niet gepusht is: --amend wijzigt de commit niet, het zet er een nieuwe voor in de plaats en de oude identifier verdwijnt.

De commit is al gepusht, ik wil hem netjes terugdraaien

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert maakt een nieuwe commit die het omgekeerde van de vorige toepast. De geschiedenis wordt langer in plaats van herschreven, en dat is precies wat je nodig hebt wanneer anderen jouw werk al hebben opgehaald. Het is de enige veilige methode op een gedeelde branch.

De commit is niet gepusht, ik wil hem weghalen

git reset --soft HEAD~1   # maakt de commit ongedaan, houdt alles in de index
git reset --mixed HEAD~1  # maakt de commit ongedaan, houdt de gewijzigde bestanden (standaardgedrag)
git reset --hard HEAD~1   # maakt de commit ongedaan en verwijdert de wijzigingen

--soft is de nuttigste: die geeft je je wijzigingen terug, klaar om anders opnieuw te committen. --hard is de enige die werk vernietigt, en hij waarschuwt niet. Typ hem alleen als je zeker bent.

Ik heb een reset –hard te veel gedaan

Nog niet alles is verloren. Git bewaart enkele weken lang het spoor van alle toestanden waar HEAD doorheen is gegaan:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

De twee gewiste commits staan er nog. Zoek de regel die bij de gewenste toestand hoort, noteer de identifier en ga ernaartoe:

git reset --hard f3951da

De reflog haalt daarentegen alleen terug wat gecommit was. Wijzigingen die nooit zijn vastgelegd, zijn definitief weg, wat een argument te meer is om vaak te committen.

De samenvatting

Je kunt nu alleen werken. Het volgende hoofdstuk voegt de anderen toe: branches, merges en conflicten. Het laatste hoofdstuk gaat daarna over het organiseren van die branches op de schaal van een team.