Les 1: Inleiding Versiebeheer en Git

Auteur

Fabrice Devaux

Publicatiedatum

16 december 2025

https://xkcd.com/1597/

https://xkcd.com/1597/

Inleiding

In deze cursus leer je werken met Git, het populairste versiebeheersysteem dat aan de basis ligt van online platformen als GitHub.

In principe kan je alle voorbeelden zelf uitvoeren. Het is zeker een goed idee om dit te doen en zelfs verder experimenteren met de verschillende commandos.

Weersta de verleiding om de exacte commandos en instructies te copy-pasten. Door zelf de commandos in te tikken zet je al een eerste stap in het onthouden en toepassen van de materie.

Misschien vraag je je af waarom Git wordt aangeleerd, en niet een van de (vele) andere systemen. In een Stack Overflow developer survey uit 2023 blijkt dat bijna 94% van de bevraagde ontwikkelaars Git gebruikt.

Als je vandaag aan de slag wil in de softwareindustrie, of gewoon als hobbyist, is kennis van Git een absolute must. Git is:

  • Populair
  • Snel en efficiënt
  • Erg geschikt voor samenwerking
  • Open Source

Versiebeheer, Wat en Waarom

Versiebeheer (of version control) is een essentieel hulpmiddel bij softwareontwikkeling. Het maakt het mogelijk om wijzigingen in de broncode systematisch bij te houden, eerdere versies terug te halen, en samen te werken zonder dat werk verloren gaat of overschreven wordt. Voor individuele ontwikkelaars betekent dit veiligheid en overzicht, voor teams betekent het efficiëntere samenwerking, duidelijke verantwoordelijkheid en minder kans op fouten.

De oorsprong van versiebeheer ligt in de jaren ’70 en ’80, toen de eerste programmeerteams behoefte kregen aan methoden om broncode te organiseren. Vroege systemen waren vaak lokaal en bestonden uit eenvoudige bestandsarchieven, zoals SCCS (Source Code Control System, 1972) en RCS (Revision Control System, 1982). In de jaren ’90 en 2000 kwamen meer geavanceerde systemen zoals CVS en later Subversion (SVN), die beter geschikt waren voor samenwerking binnen teams.

Versiebeheer is van algemeen nut, tot ver buiten het domein van softwareontwikkeling zelf. Denk bijvoorbeeld het (vroeger) vaak samengewerkt werd aan documenten of spreadsheets, door deze via email of fileservers uit te wisselen. Er werd dan automatisch aan ad-hoc-versiebeheer gedaan voor bvb. een versienummer in de bestandsnaam te plaatsen. Iedereen die ooit document als Project Plan v41_3 Final Version_2.docx heeft gezien weet hoe chaotisch deze aanpak snel kan worden.

Vergelijk dit met wat we vandaag als vanzelfsprekend vinden in applicaties als Google Docs.

Ook bij softwareontwikkeling werden vroeger vaak zogenaamde patches naar elkaar gemaild om aanpassingen voor te stellen.

From: junior@bigcorp.com
To: senior@bigcorp.com
Subject: please review

--- demos/flask/hello.py        2025-08-23 11:51:01
+++ demos/flask/hello_who.py    2025-08-24 08:49:30
@@ -3,6 +3,6 @@
 app = Flask(__name__)


-@app.route("/hello")
-def hello():
-    return "Hello!"
+@app.route("/hello/<name>")
+def hello(name):
+    return f"Hello {name}!"

Een modern versiebeheersysteem biedt tal van voordelen, o.a.

  • Een volledige en exacte geschiedenis van alle aanpassingen (wie, wat, wanneer, en waarom)
  • Je kan verschillende parallelle versies beheren van één programma of codebase
  • Maakt aanpassingen door verschillende ontwikkelaars (tegelijk!) mogelijk en werkbaar

Git Geschiedenis

Tot 2005 gebruikte de ontwikkelaars van de Linux kernel een commercieel versiebeheersysteem genaamd BitKeeper. In dat jaar verzuurde de relatie tussen het ontwikkelingsteam en het bedrijf achter BitKeeper. Dit heeft hen gemotiveerd een eigen, open-source versiebeheersysteem te schrijven. Git was geboren.

De legende zegt dat een gefrustreerd Linux Torvalds de eerste rudimentaire versie van Git op 5 dagen heeft geschreven.

De doelstellingen bij de ontwikkelingen waren

  • Snelheid
  • Eenvoudig design
  • Diepe ondersteuning voor non-lineaire ontwikkeling met duizenden ontwikkelingsstromen (zogenaamde branches)
  • Volledig gedistribueerd
  • Mogelijkheid om heel grote codebases zoals de Linux kernel efficient te beheren

Over de betekenis van de naam Git kan je eindeloos discussiëren. In de README.md van de eerst commit van Git lezen we:

    GIT - the stupid content tracker

"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronounciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room.
 - "goddamn idiotic truckload of sh*t": when it breaks

I’m an egotistical bastard, and I name all my projects after myself.
- Linus Torvalds

Installatie

In deze cursus leer je enkel werken met de Git command line interface (CLI). Er zijn tal van grafische Git clients, IDE plugins en andere hulpmiddelen. Tijdens en na deze cursus kan je daar zeker zelf mee experimenteren. Maar de CLI:

  • Is altijd en overal bruikbaar
  • Werkt precies hetzelfde op elk platform
  • Helpt je de fundamenten te begrijpen

Online platformen zoals GitHub komen uiteraard wel aan bod.

macOS

https://git-scm.com/downloads/mac

Git installeren op macOS is het makkelijkst via Homebrew, een pakketbeheer systeem waarmee je gemakkelijk heel wat extra software kan installeren.

Op de Homebrew homepage vind je een link naar “Homebrew’s laatste GitHub release”. Daar kan je, onderaan de pagina, de Homebrew installeren downloaden (bvb. Homebrew-4.6.11.pkg).

Eens Homebrew geïnstalleerd is kan je Git als volgt installeren vanuit een Terminal sessie:

$ brew install git

Linux (of WSL op Windows)

https://git-scm.com/downloads/linux

Vanuit een terminal sessie:

$ sudo apt-get install git

Of:

$ sudo dnf install git

Windows

https://git-scm.com/downloads/win

Aangeraden: ben je bekend met Windows Subsystem for Linux (WSL), volg dan de Linux instructies.

Anders download je de laatste versie vanaf bovenstaande link.

Testen

$ git --version

Documentatie

De Git documentatie is erg goed en een handige bron om bij de hand te hebben.

$ git help
$ get help -a
$ git help commit

Het uitstekende boek Pro Git is gratis beschikbaar, zoals online als in PDF of ePub formaat.

Basis Configuratie

We komen later terug op configuratiemogelijkheden van Git. Om te starten met het volgende hoofdstuk is het belangrijk om een aantal basisinstellingen aan de passen. Gebruik in onderstaande commandos je eigen naam en email adres.

git config --global user.name "John Doe"
git config --global user.email "john.doe@gmail.com"
git config --global init.defaultBranch main

Wat een defaultBranch precies is en waarom we dit aanpassen komt ook later nog aan bod.

Fundamenten

In dit hoofdstuk bekijken we een aantal basisconcepten en commandos die je dagelijks zal gebruiken.

Een belangrijk inzicht is dat we hier volledig lokaal werken en er nog geen Git “server” meespeelt.

Met een goed inzicht in deze fundamenten zullen meer geavanceerde concepten die later aan bod komen veel gemakkelijker te begrijpen zijn.

Repository aanmaken - init

Een Git repository, of kortweg repo, is een opslagplaats die de complete geschiedenis en huidige staat van een codebase bewaart, inclusief bestanden, wijzigingen en versies.

Één directory (folder) = één git repo

Je kan van elke directory een Git repo maken. Die directory hoeft niet leeg te zijn.

We starten met een eenvoudige directory met daarin een test Python programma en een README:

$ mkdir hello
$ cd hello

$ echo '# My first Git repo' > README.md
$ echo 'print("Hello Git")' > hello.py

Vanuit een directory maken (initialiseren) we een nieuwe Git repo met het command git init:

$ git init
Initialized empty Git repository in /Users/syntra/dev/hello/.git/

Het commando git status geeft informatie over de repo en zullen we nog veel gebruiken:

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
        hello.py

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

In de output zie je dat we op de branch (tak, zoals de tak van een boom) genaamd main zitten. Een branch kan je zien als een bepaalde versie van de code, met een eigen geschiedenis. Om te beginnen zal dit altijd main zijn. Wat een branch precies is, en hoe je er mee werkt, komt later nog uitgebreid aan bod.

In de output can git init zie je dat een .git directory is gemaakt in de directory.

Alle git informatie zal worden bijgehouden in deze directory (en enkel deze directory). Dit betekent dat:

  • Je zeker geen wijzigingen in deze directory mag maken!
  • Na het verwijderen van deze directory alle sporen van git weg zijn.
$ rm -rf .git
$ git status
fatal: not a git repository (or any of the parent directories): .git

Lifecycle van een Bestand

stateDiagram-v2
    Untracked --> Staged: git add
    Staged --> Committed: git commit
    Committed --> Modified: edit
    Modified --> Staged: git add
    Committed --> Untracked: git rm

Elk bestand begint in de untracked state. Dit zien we duidelijk in de output van het git status commando. Dit betekend dat het bestand nog onbekend is voor Git en niet “gevolgd” wordt.

Eenmaal een bestand gekend is zal het altijd in één van de drie mogelijke states verkeren: modified, staged of committed

git add

Om een nieuw bestand toe te voegen aan de Git repo gebruik je eerst het commando git add. De state van het bestand verandert dan naar staged. Het bestand zit dan in de zogenoemde staging area. In de staging area verzamel je een set bestanden en wijziging die als een transactie toegevoegd zullen worden in het versie-systeem. Het is dus een soort wachtplaats.

$ git add hello.py

$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   hello.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

Wat gebeurt er als een bestand dat al gestaged is (maar nog niet gecommit) wordt gewijzigd?

$ echo '# Test' >> hello.py

$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   hello.py

Het hello.py bestand is nu gestaged en niet gestaged tegelijk! Wanneer een bestand wordt gestaged houdt Git de exacte versie van het bestand bij op dat moment. M.a.w. de oorspronkelijke inhoud van het bestand is not steeds gestaged, maar de latere aanpassing niet. We zouden nu enkel de oorspronkelijke versie kunnen committen, of de nieuwe aanpassingen ook stagen (opnieuw met git add hello.py).

git commit

Nadat de gewenste bestanden en wijzigingen zijn klaargezet in de staging area kunnen ze als een geheel worden toegevoegd aan de Git-history met het commando git commit. Met het argument -m/--message geeft je een beschrijving van de wijzigingen.

$ git commit -m "Add initial hello.py version"
[main (root-commit) f39a6cc] Add initial hello.py version
 1 file changed, 1 insertion(+)
 create mode 100644 hello.py

$ git status
On branch main
nothing to commit, working tree clean

git status vertelt ons hier dat de working tree clean is. De working tree (of working directory) is de verzameling bestanden die overeenkomt met de huidige branch (of commit). M.a.w. de bestanden die je op dat moment in de directory van je repo kan zien en gebruiken. De working tree is “clean” wanneer er geen veranderingen zijn t.o.v. de gecommitte versie.

Oefening

Maak een kleine aanpassing in hello.py. Gebruik git status om te bevestigen dat de state van hello.py nu modified is.

Stage deze aanpassing als ook het README.md bestand. Commit dan de aanpassingen. Controleer het resultaat met git status

Oplossing

Maak een aanpassing in hello.py met je editor. Bvb.

message = "Hello from my first Git repo"
print(message)
$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   hello.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git add hello.py README.md

$ git commit -m "Improve hello.py and add README"
[main 245bfa1] Improve hello.py and add README
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 README.md

$ git status
On branch main
nothing to commit, working tree clean

git rm

Het kan gebeuren dat een bestand per ongeluk is in de Git-history is beland. Of gewoon niet meer nodig is. Om een bestand uit Git te verwijderen gebruik je het git rm commando.

Opgelet

Met git rm wordt het bestand uit Git en het systeem verwijderd. Om enkel uit Git te verwijderen gebruik je het --cached argument. Het bestand blijft dan gewoon bestaan en is terug in de untracked state.

$ git rm --cached README.md

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

Net als bij git add is het verwijderen van een bestand eerst toegevoegd aan de staging area. Om de verwijdering (samen met eventuele andere aanpassingen) effectief door te voeren gebruiken we opnieuw git commit

$ git commit -m "Remove README"
[main 80b00ac] Remove README
 1 file changed, 1 deletion(-)
 delete mode 100644 README.md

Commit Geschiedenis (History)

Elke commit bevat o.a. volgende informatie:

  • ID / hash
  • Auteur (wie)
  • Datum (wanneer)
  • Beschrijving (waarom)
  • Diff (wat)

git log

Met het git log commando kan je de commit geschiedenis bekijken, vanaf de laatste commit. Met het commando git help log zie je dat er erg veel opties en mogelijkheden zijn. We bekijken hier de meest gebruikte.

$ git log
commit 3ecf8d528d7a591210c53e93a5f87787284103fd (HEAD -> main)
Author: Fabrice Devaux <fabrice.devaux@gmail.com>
Date:   Sun Aug 24 14:56:26 2025 +0200

    Improve hello.py and add README

commit f39a6cce08ebbb1a63616030322e46b4ff4d653c
Author: Fabrice Devaux <fabrice.devaux@gmail.com>
Date:   Sun Aug 24 14:31:08 2025 +0200

    Add initial hello.py version

(HEAD is een reference en main is een branch - hier komen we later op terug)

–oneline

Met git log --oneline krijg je, zoals te verwachten, een enkele lijn per commit.

$ git log --oneline
3ecf8d5 (HEAD -> main) Improve hello.py and add README
f39a6cc Add initial hello.py version

Je ziet dat de commit hash ingekort is tot de eerste 7 karakters. Dit is gebruikelijk genoeg om een commit aan te duiden.

–stat

Met git log --stat krijg je voor elke commit de “statistieken” van de wijzigingen: welke bestanden, hoeveel lijnen en het soort wijziging.

Je kan de opties vaak ook combineren. Zo zal git log --oneline --stat de commit informatie op 1 lijn plaatsen, gevolgd door de statistieken.

$ git log --oneline --stat
3ecf8d5 (HEAD -> main) Improve hello.py and add README
 README.md | 1 +
 hello.py  | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
f39a6cc Add initial hello.py version
 hello.py | 1 +
 1 file changed, 1 insertion(+)

filename

Door na het git log commando een bestandsnaam te plaatsen krijgen we enkel de commits te zien die betrekking hebben op dat bestand.

$ git log --oneline README.md
3ecf8d5 (HEAD -> main) Improve hello.py and add README

Veranderingen ongedaan maken

Restore

Met git restore kan je veranderingen die nog niet gestaged zijn ongedaan maken. In het lifecycle diagram: van modified naar committed.

Merk op dat de output van git status je het juiste commando al aangeeft.

$ echo "woops" >> hello.py

$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   hello.py

no changes added to commit (use "git add" and/or "git commit -a")

$ git restore hello.py

$ git status
On branch main
nothing to commit, working tree clean
Opgelet

git restore is permanent. De veranderingen zijn nooit toegevoegd in de Git geschiedenis dus kunnen ook niet terug opgehaald worden.

Als het bestand geopend is in een editor zoals VSCode kan je mogelijks wel nog de veranderingen terug krijgen.

Unstage (restore –staged)

Met git restore --staged kan je veranderingen die wel al gestaged zijn ongedaan maken. In het lifecycle diagram: van staged naar modified.

Opnieuw krijg je van git status al het geschikte commando.

$ echo "woops" >> hello.py

$ git add hello.py

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   hello.py

$ git restore --staged hello.py

$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   hello.py

no changes added to commit (use "git add" and/or "git commit -a")

$ git restore hello.py

Veranderingen Bekijken

Git houdt alle versies en details super-efficient bij. Het is dan ook belangrijk om snel en gemakkelijk specifieke versies en verschillen te kunnen ophalen.

Een diff is een weergave van de verschillen tussen twee versies van een bestand of code, waarbij zichtbaar wordt welke regels zijn toegevoegd, gewijzigd of verwijderd. Een diff is niet specifiek aan Git – zo zal het Linux commando diff a.txt b.txt de verschillende weergeven tussen de bestanden a.txt en b.txt.

Nieuwe wijzigingen

Wijziging die nog niet gestaged zijn bekijk je met het git diff commando

$ echo "This is a new line" >> README.md

$ git diff
diff --git a/README.md b/README.md
index 3836229..9ebb1b9 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # My first Git repo
+This is a new line

git diff toont alleen wijzigingen in bestanden die al getrackt worden door Git. Een nieuw bestand zal je dus niet te zien krijgen!

Om de wijziging die wel al gestaged zijn te zien gebruik je het git diff --staged commando.

$ git add README.md

$ git diff --staged
diff --git a/README.md b/README.md
index 3836229..9ebb1b9 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # My first Git repo
+This is a new line

Bestaande Commits en Diffs

Om de inhoud van een bestaande commit te bekijken is er het commando git show.

$ git show 3ecf8d5
commit 3ecf8d528d7a591210c53e93a5f87787284103fd (HEAD -> main)
Author: Fabrice Devaux <fabrice.devaux@gmail.com>
Date:   Sun Aug 24 14:56:26 2025 +0200

    Improve hello.py and add README

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..3836229
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+# My first Git repo
diff --git a/hello.py b/hello.py
index 078d6bf..e0f8470 100644
--- a/hello.py
+++ b/hello.py
@@ -1 +1,2 @@
-print("Hello Git")
+message = "Hello from my first Git repo"
+print(message)

Met git log -p (-p voor patch) krijgen we dezelfde informatie voor een lijst commits.

$ git log -p
commit 3ecf8d528d7a591210c53e93a5f87787284103fd
Author: Fabrice Devaux <fabrice.devaux@gmail.com>
Date:   Sun Aug 24 14:56:26 2025 +0200

    Improve hello.py and add README

diff --git a/README.md b/README.md
...

commit f39a6cce08ebbb1a63616030322e46b4ff4d653c
Author: Fabrice Devaux <fabrice.devaux@gmail.com>
Date:   Sun Aug 24 14:31:08 2025 +0200

    Add initial hello.py version

diff --git a/hello.py b/hello.py
new file mode 100644
...

Met git diff kunnen we ook een diff krijgen met alle wijzigingen tussen twee gegeven commits.

git diff f39a6cc..3ecf8d5 geeft alle verschillende tussen commits en f39a6cc en 3ecf8d5.

Git Blame

git blame (letterlijk beschuldigen) is een superhandig commando waarmee je lijn per lijn precies kan zien wie als laatste die lijn heeft aangepast, wat de commit hash is, en wanneer dit gebeurd is.

$ ❯ git blame hello.py
455cc537 (Fabrice Devaux 2025-09-07 09:30:14 +0200 1) """Module to print a welcome message"""
455cc537 (Fabrice Devaux 2025-09-07 09:30:14 +0200 2)
3ecf8d52 (Fabrice Devaux 2025-08-24 14:56:26 +0200 3) message = "Hello from my first Git repo"
3ecf8d52 (Fabrice Devaux 2025-08-24 14:56:26 +0200 4) print(message)

Ons klein test-projectje bevat natuurlijk niet veel veranderingen. Wil je een idee krijgen van de kracht van dit commando, bekijk dan eens een groter codebase zoals Flask: https://github.com/pallets/flask/blame/main/src/flask/app.py.

Oefeningen

  1. Voeg een nieuw bestand test.py toe (commit)
  2. Pas iets aan in README.md en test.py
  3. Stage de aanpassingen in README.md
  4. Bekijk de commit geschiedenis en status van de repo
  5. Bekijk de uitstaande aanpassingen
  6. Maak alle uitstaande aanpassingen ongedaan. Gebruik enkel git commandos.
  7. Verwijder het test.py bestand en commit deze verandering

Configuratie

git config

Git heeft een heleboel configuratieparameters. De meesten zul je echter nooit moeten aanpassen.

De configuratie wordt bewaard in gewone tekst-bestanden en kan in 3 locaties voorkomen. Elke locatie overschrijft de waarden van de vorige.

  1. /etc/gitconfig (“C:\ProgramData\Git\config op Windows), van toepassing op iedere gebruiker
  2. ~/.gitconfig of ~/.config/git/config (C:\Users\$USER\.gitconfig op Windows), van toepassing op jou gebruiker
  3. <repo-directory>/.git/config, van toepassing op die repo

Die bestanden pas je in principe niet met de hand aan. Met het git config commando kunnen we configuratie bekijken en aanpassen. Standaard past die de configuratie aan voor de huidige repo. Met --global pas je de configuratie aan voor jou gebruiker en met --system voor iedere gebruiker.

Met git help -c krijg je een lijst van alle mogelijke parameters. Om te beginnen zijn een maar een paar die we willen aanpassen.

Identiteit

De user.name en user.email parameters worden gebruikt in commits. Hier willen we onze eigen identiteit instellen - zeker in repos waar we onze code willen delen, of waar we zullen samenwerken met andere ontwikkelaars.

Omdat dit in principe hetzelfde zal zijn voor elke repo gebruiken we --global. Met git get kunnen we de waarde van een parameter controleren.

$ git config --global user.name "Fabrice Devaux"
$ git config --global user.email "fabrice.devaux@gmail.com"

$ git config get user.name
Fabrice Devaux

Editor

Soms heeft een Git commando tekst input nodig van de gebruiker. Bijvoorbeeld bij het git commit commando wanneer geen commit message is meegegeven met de -m parameter. Git zal dan je tekst editor openen zodat je daar een commit message kan samenstellen.

Op Linux, MacOS en WSL zal die default de waarde van de $EDITOR variable zijn (meestal vim of emacs). Als je met vim kan werken is die een goede optie. Met de core.editor configuratie parameter kunnen we Git een andere editor laten gebruiken.

Voorbeeld 1: VSCode gebruiken op Linux, MacOS of WSL:

$ git config --global core.editor "code --wait"

Voorbeeld 2: Notepad++ gebruiken op Windows:

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Configuratie overzicht

Met git config --list --show-origin krijg je een overzicht van alle aangepaste configuratie en waar die configuratie ingesteld is.

$ git config --list --show-origin
file:/Users/dfabrice/.gitconfig core.editor=code --wait
file:/Users/dfabrice/.gitconfig user.email=fabrice.devaux@gmail.com
file:/Users/dfabrice/.gitconfig user.name=Fabrice Devaux

Bestanden negeren (.gitignore)

Er zullen altijd een aantal bestanden of directories zijn die je nooit wilt committen. Je kan Git configureren om deze altijd te negeren m.b.v. het .gitignore bestand. Hierin plaats je telkens op een aparte lijn de naam of een expressie van wat genegeerd moet worden.

Het .gitignore bestand zelf voeg je wel toe in Git.

.gitignore
__pycache__/
.vscode/
*.temp
$ git add .gitignore

$ git commit -m "Add .gitignore"
[main c758209] Add .gitignore
 1 file changed, 3 insertions(+)
 create mode 100644 .gitignore

$ touch test.temp

$ git status
On branch main
nothing to commit, working tree clean