Lokaal versiebeheer: Git

Git installeren

Het versiebeheer systeem dat we in dit opleidingsonderdeel zullen gebruiken is Git. ‘Git’ staat voor Global Information Tracker of met andere woorden Git wordt gebruikt om informatie over bestanden te volgen. Via volgende link kan je alle up-to-date informatie terugvinden over hoe je Git op je besturingssysteem kan istalleren: Installatie procedure Git

Je kan checken of Git al geïnstalleerd is op je WSL door de versie ervan op te vragen via de CLI met git --version. Indien je geen error krijgt, is Git klaar voor gebruik. Als Git nog niet geïnstalleerd zou zijn kan je dit eenvoudig installeren met sudo apt install git.

Git gui en Git bash

Het is ook mogelijk een GUI voor Git te installeren, maar deze gaan we niet gebruiken. Dit is overigens ook nog niet mogelijk aangezien we enkel een CLI interface hebben voor onze WSL.

De git-gui app is een beginner vriendelijke omgeving om gemakkelijk met versiebeheer aan de slag te gaan. In de SES-lessen willen we je echter de ‘correcte’ manier aanleren om als software ontwikkelaar overweg te kunnen met verschillende handige tools zoals Git. Ook daarom gaan we de grafische interface van Git niet gebruiken.

De git workflow

(Image Src)

In Git doorloopt een bestand verschillende statussen tijdens zijn levenscyclus. Wanneer een bestand voor het eerst wordt aangemaakt, is het untracked, wat betekent dat Git het nog niet volgt. Zodra je het bestand toevoegt aan de repository met git add, wordt het staged. Dit betekent dat het klaar is om gecommit te worden. Als je het bestand daarna bewerkt, wordt het modified. Om deze wijzigingen op te nemen in de volgende commit, moet je het bestand opnieuw stagen met git add. Wanneer je tevreden bent met de wijzigingen, gebruik je git commit om de wijzigingen definitief vast te leggen (commit) in de repository. Als je een bestand niet langer nodig hebt, kun je het verwijderen met git rm, waardoor het bestand uit de repository wordt verwijderd en de status van het bestand verandert. Gedurende deze cyclus kan een bestand ook de status unmodified hebben, wat betekent dat er geen wijzigingen zijn aangebracht sinds de laatste commit.

Git correct configureren

Om van start te kunnen gaan, moeten we Git eerst nog correct configureren. Dit doen we via de volgende commando’s:

$ git config --global user.email "jouwemail@voorbeeld.com"
$ git config --global user.name "VoornaamAchternaam"

We gaan in de volgende les een account aanmaken op een cloudplatform waarmee we ons versiebeheer gaan kunnen uitbreiden met cloud opslag en de mogelijkheid om samen te werken aan hetzelfde project. Hiervoor gaan we een gratis account moeten aanmaken met een emailadres en een username. Dit moeten dezelfde worden als de gegevens die je zojuist hebt geconfigureerd. Je kan deze gegevens later nog aanpassen.

Soms ga je een text editor moeten gebruiken om bijvoorbeeld een boodschap mee te geven bij elke nieuwe ‘versie’ die we gaan opslaan. Standaard wordt hier Vim voor gebruikt, maar aangezien dit niet zo beginnersvriendelijk is, veranderen we de default liever naar iets anders zoals Nano. Dit doe je via het volgende commando:

$ git config --global core.editor nano

Een directory initialiseren als een Git directory

Om van een directory een git directory te maken en alle veranderingen beginnen tracken gebruiken we het commando:

$ git init

Er verschijnt een verborgen folder in je directory genaamd .git. In die folder zal git alles bewaren om de veranderingen te tracken en een geschiendenis van alle versies bij te houden.

Checking, staging and committing changes

Met het commando $ git status kan je controleren in welke staat alle files/directories zich bevinden. Een file/folder kan zich in één van drie toestanden bevinden:

• Modified: de file is aangepast maar nog niet gestaged.
• Staged: de file is gestaged en klaar om gecommit te worden.
• Committed: de file is sinds zijn laatste commit niet meer aangepast.
• (Untracked: dit geldt enkel voor files/folders die juist aangemaakt zijn en nog nooit gecommit werden)

Een voorbeeld output ziet er als volgt uit:

arne@LT3210121:~/gittest$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached ..." to unstage)
        new file:   eenfile.txt

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   eenfile.txt

Untracked files:
  (use "git add ..." to include in what will be committed)
        filetwee.txt

Met het commando $ git diff kan je de verschillen zien tussen de huidige staat van je files/folders versus de staat van de files/folders in de laatste commit.

Met het commando $ git add <filenaam> kan je afzonderlijk modified files naar de staging area ‘verplaatsen’. Volgens een goede version control strategy, is dit de manier om wijzigingen te stagen. Op die manier kan je gerichte commits maken die over een bepaald onderwerp gaan. In de praktijk wordt er soms echter voor snelheid gekozen. Zo kan je met $ git add . alle wijzigingen en nieuwe files in een keer stagen.

Met het commando $ git commit kan je alle files committen die gestaged zijn. Je teksteditor opent en je wordt gevraagd een message mee te geven met de commit. Probeer steeds een concrete boodschap mee te geven met elke commit bv. “Bug opgelost waarbij alles vetgedrukt stond”. Probeer elke commit message zo zinvol mogelijk te maken. Dit maakt het later makkelijk om terug te keren naar een belangrijke ‘versie’ van je broncode. Elke commit krijgt ook een specifieke hash zodat je gemakkelijk naar een specifieke ‘versie’ (commit) kan refereren.

• Alle modified files stagen met 1 commando: $ git add .
• Onmiddellijk een commit message meegeven binnenin het commit commando: $ git commit -m "mijn commit message"
• combinatie van de twee bovenstaande commando’s: $ git commit -a -m "mijn commit message"
  • Opgelet Met $ git commit -a worden nieuwe files niet toegevoegd. Gebruik hier dus nog $ git add voor.

Undo changes

git status geeft je ook informatie over hoe je files/folders kan unstagen en zelfs de veranderingen van files kan terugbrengen naar hoe ze eruit zagen tijdens de laatste commit. Gebruik: git rm --cached <file>... om te unstagen en git restore <file>... om wijzigingen terug te draaien (te discarden).

Bekijk de version tree (log)

Het commando $ git log wordt gebruikt om een lijst te zien van all je commits in chronologische volgorde, startend bij de laatste commit. Dat commando geeft veel informatie mee voor elke commit. Wil je liever een korter overzicht? Gebruik dan $ git log --oneline. (Met de --graph flag kan je ook de boomstructuur weergeven waar we zo dadelijk op terugkomen)

Met de flag --all kan je ervoor zorgen dat je zeker ben dat je alle branch information en tags te zien krijgt

Teruggaan naar vorige ‘versies’

Er bestaan commando’s die we kunnen gebruiken om naar een vroegere commit terug te keren. Ze werken echter op een verschillende manier en het is belangrijk dat je deze verschillen goed kent.

• $ git reset <hash van de commit>: hiermee ga je terug naar een vorige commit en worden alle commits die erna gebeurden verwijderd.
• $ git checkout <hash van de commit>: hiermee kan je tijdelijk terugkeren naar een vorige commit. Je zit hier dan in een soort virtuele omgeving waar je ook commits kan aanbrengen. Om dan terug te keren naar de HEAD van de versiegeschiedenis gebruik je:
  • $ git switch -c <branchname> : om je nieuwe virtuele commits op te slaan in een echte nieuwe branch.
  • $ git switch - : om terug te keren zonder je nieuwe virtuele commits bij te houden.

Snel een extra wijziging aanbrengen aan een vorige commit

Soms ga je snel te werk en heb je een commit gedaan, maar is er nog een kleine wijziging die eigenlijk ook nog best tot die commit hoort. In de plaats van een volledig nieuwe commit te doen kan je via git commit --amend je nieuwe gestagede files/folders toevoegen aan de laatste commit en de commit message eventueel wijzigen.

Dit is ook een handige manier om incrementeel en regelmatig een commit te doen, ook al denk je dat je werk nog geen volwaardige commit vereist. Je blijft gewoon stap na stap delen toevoegen tot je tevreden bent.

Branching

Het fijne aan Git is dat je parallel aan verschillende versies van je project kan werken door gebruik te maken van branching. Je start letterlijk een nieuwe tak waar je eigen commits kan aan toevoegen. Zo kan elk teamlid bijvoorbeeld zijn eigen branch aanmaken. Of je kan een brach aanmaken om aan een nieuwe feature te werken zonder dat je schrik moet hebben om problemen te creëren op de main branch.

Je maakt een nieuwe branch aan met het commando: $ git branch <branchnaam> Je kan de verschillende branches oplijsten met: $ git branch

• Het * symbool duidt de actieve branch aan. Je kan naar een bepaalde branch gaan met: $ git checkout <branchnaam> Je kan een branch deleten met: $ git branch -d <branchnaam>

Om een grafische voorstelling van de braches te laten printen bij het log commando gebruik je de --graph flag.

Merging

Je kan de commits van een zijtak nu terug toevoegen aan de historie van een andere tak. Dit doe je met het commando $ git merge <branchname>. Wil je bijvoorbeeld de wijzigingen van de new_feature branch mergen met de main branch, dan moet je eerst zien dat je je in de main branch bevindt en dan gebruik je het volgende commando: $ git merge new_feature

Merge conflicts

Wanneer je op twee verschillende branches echter commits heb die verschillende aanpassingen maken aan hetzelfde stukje code in je project dan ontstaat er een merge conflict. Je zal dan beide versies voorgeschoteld krijgen en jij moet dan de versie verwijderen die je niet wilt behouden. Dan pas kan de ‘merge’ succesvol afgerond worden.

.gitignore

Soms wil je dat een file niet wordt bijgehouden door git. Hier komen we in het gedeelte over remote repositories op terug. De files/folders die niet getracked mogen worden, moeten we in het bestand .gitignore toevoegen.

# Negeert het bestand secret.txt in de root directory.
/secret.txt 

# Negeert alle bestanden in de node_modules directory.
node_modules/

# Negeert de gehele directory build en alle subdirectories.
/build/

# Negeert alle bestanden met de extensie .log.
*.log 

# Negeert alle bestanden in de temp directory, maar niet de subdirectories.
/temp/*

# Negeert alle .tmp bestanden in alle directories en subdirectories.
**/*.tmp: 

# Negeert alle bestanden in de logs directory.
/logs/*
# Negeert NIET het bestand debug.log in de logs directory.
!/logs/debug.log: 

# Negeert alle bestanden die beginnen met een tilde (~).
~* 

Tagging

Om bepaalde belangrijke commits snel terug te vinden, kan je gebruik maken van tags.

• Je kan de bestaande tags oplijsten met: $ git tag
• Je kan de huidige commit taggen met bijvoorbeeld: $ git tag vX.X
• Je kan een specifieke commit taggen met bijvoorbeeld: $ git tag vX.X <hashcode commit>
• Je kan tags deleten met bijvoorbeeld: $ git tag -d vX.X

**Eens een commit een tag heeft gekregen kan je er ook naar refereren via de tag.

Indien je een bestaande tag wil verplaatsen, moet je ze eerst deleten en daarna toevoegen aan de nieuwe commit.

Belangrijk

We hebben hier enkel de basis commando’s aangehaald met een paar van de meest gebruikte manieren waarop ze gebruikt worden. Voor meer diepgang en achtergrond van alle git commando’s verwijs ik naar het Pro Git handboek. Vooral hoofdstuk 1 t.e.m. 3 zijn voor jullie interessant.

Oefeningen

1. Maak een git directory aan
2. Voeg één of meerdere tekstbestanden toe aan deze directory. Maak eventueel subfolders …
3. Gebruik $ git status om te zien wat er allemaal gecommit kan worden.
4. Commit deze veranderingen.
5. Maak aanpassingen aan de tekstbestanden en commit.
6. Keer terug naar de eerste commit via $ git reset
7. Bestudeer de output van $ git log
8. Maak een nieuwe branch en chechout naar die nieuwe branch
9. Voeg in deze branch nieuwe textbestanden toe en commit de verandering in die nieuwe branch.
10. Open File Explorer en doe een checkout terug naar de main branch. Zie je de nieuwe files verdwijnen/verschijnen wanneer je tussen de twee branches wisselt?
11. Merge je nieuwe branch met de main branch.
12. Maak veranderingen in de main branch en commit.
13. Switch terug naar je andere branch en maak op dezelfde plaats veranderingen en commit. Zo kan ga je een mergeconflict opwekken.
14. Probeer nu weer je nieuwe branch te mergen met je main branch. Je zal eerst het merge conflict moeten oplossen
15. Tag je eerste commit met v1.0 en tag je laatste commit met v2.0.
16. Doe een git checkout naar je eerste commit door gebruik te maken van je nieuwe tags.
17. Probeer van alle bovenstaande stappen een schets te maken om zo na te gaan of je alle commando’s goed begrijpt.

Indien niet afgewerkt in het applicatiecollege, gelieve thuis af te werken tegen volgende les.

Extra

Wildcards en commando’s aaneenschakelen

Wildcards kunnen gebruikt worden om naar meerdere files tegelijk te verwijzen. Zo kan je de wildcard ‘_’ gebruiken om naar alle files die eindigen op ‘.txt’ te verwijzen.
Bijvoorbeeld: **$ git add _.txt**

Je kan commando’s ook aaneenschakelen met ‘;’ zodat meerdere commando’s onmiddellijk na elkaar uitgevoerd worden
Bijvoorbeeld: $ git add . ; git commit -m "initial commit"

Extra bronnen

• Pro Git handboek, vooral hoofdstuk 1 tot en met 3.

• git - the simple guide

• Code Forest: Git VS SVN

• the Harvard.edu guide to Git

• Beginner vriendelijke Git en Github tutorials

• Tools & Concepts for Mastering Version Control with Git

• Wil je meer inzicht in hoe git achter de schermen precies werkt? Lees dan zeker dit artikel eens! Die geeft je op een toegankelijke manier uitleg over hoe git wijzigingen opslaat, wat de staging area precies is, etc. (Opmerking: het artikel begint met een vergelijking met SVN; dat is een ander/ouder versiecontrolesysteem.)

Remote repositories: Github

Types van versiebeheer systemen

Git is een gedecentraliseerd versiebeheer systeem waarbij de hele repository inclusief historiek lokaal wordt geplaatst zodra een clone commando wordt uitgevoerd. Oudere gecentraliseerde systemen zoals SVN en CVS bewaren (meta-)data op één centrale plaats: de version control server. Voor dit vak wordt resoluut voor git gekozen.

Onderstaande Figuur geeft het verschil weer tussen een gecentraliseerd versioneringssysteem, zoals SVN, CVS en MS SourceSafe, en een gedecentraliseerd systeem, zoals Git. Elke gebruiker heeft een kopie van de volledige repository op zijn lokale harde schijf staan. Bij SVN communiceren ‘working copies’ met de server. Bij Git communiceren repositories (inclusief volledige history) met eender welke andere repository. ‘Toevallig’ is dat meestal een centrale server, zoals Github.com, Gitlab.com of BitBucket.com.

(Image Src)

Andere populaire platformen zijn Gitlab, Codeberg, Gitea (self-hosted), … Deze software platformen voorzien een extra laag bovenop Git (de web UI) die het makkelijk maakt op via knoppen acties uit te voeren. Het voegt ook een social media esque aspect toe: comments, requests, issues, …

Remote repository met Github

“… GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code. …” source

Cloud based storage is zeer populair geworden en voor goede redenen:

• Je hebt een backup van al je data.
• Je kan op meerdere verschillende pc’s aan hetzelfde project werken zonder met een USB-stick dingen te copy pasten.
• Je kan met meerdere personen aan hetzelfde project werken zonder doorsturen van verschillende file versies via mail.

Github is zeer populair en wordt door veel softwareontwikkelaars en bedrijven gebruikt. Wij zullen dit platform dan ook gebruiken in dit opleidingsonderdeel en het is ook aangeraden dit in de toekomst voor je softwareprojecten te gebruiken.

GitHub is nu eigendom van Microsoft en is closed source software. Je kan wel de meeste features volledig gratis gebruiken. Wil je later toch liever een open source alternatief gebruiken? Dan is Gitlab een goed alternatief en werkt zeer gelijkaardig aan Github. Gitea is een goed self-hosted optie

Een account aanmaken, 2FA instellen, SSH key toevoegen

Voordat we van start kunnen gaan moeten we eerst een gratis account aanmaken. Verder moeten we ook nog een aantal belangrijke instellingen veranderen voordat we van de services gebruik kunnen maken.

Aangezien het stappenplan voor het aanmaken van een account en de gewenste instellingen wel eens kan wijzigen refereren we hieronder naar de officiële bronnen die door de ontwikkelaar up-to-date gehouden worden:

• Account aanmaken op Github (Let op! gebruik hetzelfde email adres en dezelfde username die je hebt geconfigureerd in je lokale Git om het process zo vlot mogelijk te laten verlopen)
• 2FA instellen voor je account (Let op! Verplicht sinds eind 2023)
• SSH instellen voor je account (Let op! Je kan geen contributies meer pushen naar repositories over https met enkel je username en wachtwoord)

Handige video-tutorials:

• YT - 2FA instellen voor je account
• YT - SSH instellen voor je account

Repositories clonen en veranderingen fetchen, pullen & pushen

Je kan via de webinterface van Github nieuwe repositories aanmaken. Github geeft je dan alle nodige instructies/commando’s om oftewel die remote repo te koppelen aan een bestaande lokale Git directory of een nieuwe lege repo lokaal te clonen.

Vanaf nu bestaat er een link tussen de lokale repository en de remote repository.

• Je kan nieuwe aanpassingen van je remote repository pullen naar (≈ synchroniseren met) je lokale repo met:
  • $ git pull: Dit haalt alle veranderingen binnen en past ze onmiddelijk toe
  • $ git fetch: Dit haalt alle veranderingen binnen maar zo worden nog niet gemerged met jouw lokale versie. Dit doe je met $ git merge. (git pull is dus eigenlijk een aaneenschakeling van git fetch en git merge)
• Je kan nieuwe aanpassingen van je lokale repository pushen naar je remote repo met:
  • $ git push origin: Dit pusht enkel je huidige branch.
  • $ git push origin --all: Dit pusht de wijzigingen op alle branches.
  • $ git push origin --tags: Dit pusht alle tags die nog niet aanwezig zijn op de remote repo.

Collaboration made easy

Door een teamgenoot als collaborator toe te voegen aan je remote repository kan hij/zij de repo lokaal clonen en ook wijzigingen via pushen en pullen. Door dit te combineren met branching waarbij elke collaborator bijvoorbeeld een eigen branch aanmaakt, kan je een zeer efficiënte online workflow creëren om remote te kunnen samen werken aan software projecten.
In principe kan iedereen een public remote repository clonen, maar ze gaan geen veranderingen kunnen pushen. (Hiervoor gebruik je fork en pull requests)

Collaborative workflow: to minimize merge conflicts and other problems

• Regularly pull all changes into your local directory.
• Regularly keep your branch up-to-date by merging master branch into it.
• (Merge the changes on your branch to the master branch when nessecary)
• Regularly push to remote directory.

Forking en pull requests

Je kan een public repository waar je geen collaborator van bent forken (≈ kopiëren) naar je eigen Github. Zo kan je toch nieuwe aanpassingen pushen naar ‘jouw kopie’ van de repository. Github houd echter bij vanwaar jouw fork afkomstig is. Op die manier kan je een pull request aanvragen aan de eigenaar van de originele repo. Die persoon kan jouw aanpassingen dan nakijken en toevoegen aan zijn/haar repo door de pull request te accepteren en mergen.

Een waarheidsgetrouw voorbeeld ziet er als volgt uit:

• Je wil een kleine software developer helpen door een bug op te lossen.
• Je forked de repository van de software.
• Je fixed de bug, commit en pushed de aanpassing naar jouw fork van de software repo.
• Je dient een pull request in bij de originele repo van de software.
• De eigenaar vindt jouw oplossing geweldig en merged hem met zijn eigen repo.

Op deze manier kan je zeer gemakkelijk je steentje bijdragen aan de wereld van open source software en dit maakt het principe van open source ook juist mede zo aantrekkelijk.

Oefeningen

1. Maak in je Github een repository aan voor je Git directory uit de vorige oefenreeks.
2. Koppel je lokale repo aan je remote repo en push je versiegeschiedenis naar Github.
   • Push ook je tags mee naar de remote repo en controleer of ze te zien zijn bij versions
3. Clone op een andere plaats op je computer je remote repository
4. Maak veranderingen aan de files, commit en push
5. Fetch of pull nu die veranderingen in de originele directory.
   • Denk na over het verschil tussen fetch en pull.
6. Bestudeer de online user interface van Github voor het beheren van je remote repositories
7. Voeg een medestudent toe als collaborator aan het project.
8. Laat die student je repo clonen, veranderingen aanbrenge, committen en pushen.
9. Pull nu de veranderingen van je teamgenoot in je eigen local repository
10. Laat je als collaborator verwijderen
11. Fork nu de repository van je medestudent, maak aanpassingen en submit een pull request.
12. Bestudeer nu grondig de git log van je repository. Kan je alle veranderingen volgen?
13. (Submit een issue in je eigen remote repository, los de issue op met een commit en gebruik de issuenummer met het sleutelwoord ‘Close’ (Close #<issuenummer>) om de issue automatisch op te lossen)

Extra

De Git workflow

Een typische workflow is als volgt:

1. git clone [url]: Maakt een lokale repository aan die je op Github hebt gecreëerd. Het commando maakt een subdirectory aan.
2. Doe je programmeerwerk.
3. git status en git diff: Bekijk lokale changes voordat ze naar de server gaan.
4. git add [.]: Geef aan welke changes staged worden voor commit
5. git commit -m [comment]: commit naar je lokale repository. Wijzingen moeten nu nog naar de Github server worden gesynchroniseerd.
6. git push: push lokale commits naar de Github server. Vanaf nu kan eender wie die meewerkt aan deze repository de wijzigingen downloaden op zijn lokaal systeem.
7. git pull: pull remote changes naar je lokale repository. Wijzigingen moeten altijd eerst gepushed worden voordat iemand anders kan pullen.

Ik zie niet alle branches lokaal die wel op Github staan, hoe komt dat?

Een git pull commando zal soms in de console ’new branch [branchnaam]’ afdrukken, maar toch zal je deze niet tot je beschikking hebben met het git branch commando. Dat komt omdat branches dan ook nog (lokaal) getracked moeten worden:

1. Controleer welke branch je lokaal wilt volgen met git branch -r
2. Selecteer een bepaalde branch, waarschijnlijk origin/[naam]
3. Track die branch lokaal met git branch --track [naam] origin/[naam]
4. Vanaf nu kan je ook switchen naar die branch, controleer met git branch

Merk op dat een branch verwijderen met git branch -d enkel gaat bij lokale branches. Een remote branch verwijderen wordt niet met het branch subcommando gedaan, maar met git push origin --delete [branch1] [branch2] ....

Bug tracking met Github

Enkele ‘kleine probleempjes’ in software worden al snel een hele berg aan grote problemen als er niet op tijd iets aan wordt gedaan. Bedrijven beheren deze problemen (issues) met een bug tracking systeem, waar alle door klant of collega gemeldde fouten van het systeem in worden gelogd en opgevolgd. Op die manier kan een ontwikkelaar op zoek naar werk in deze lijst de hoge prioritaire problemen identificeren, oplossen, en terug koppelen naar de melder.

graph LR;
    Bug[Bug discovery]
    Report[Bug report]
    Backlog[Bug in backlog met issues]
    Prio[Bug in behandeling]
    Fix[Bug fixed]
    Bug --> Report
    Report --> Backlog
    Backlog --> Prio
    Prio --> Fix

De inhoud van deze stappen hangt af van bedrijf tot bedrijf, maar het skelet blijft hetzelfde. Bugs worden typisch gereproduceerd door middel van unit testen op een bepaalde git branch om de bestaande ontwikkeling van nieuwe features niet in de weg te lopen. Wanneer het probleem is opgelost, wordt deze branch gemerged met de master branch:

graph LR;
    masterx[Master branch x]
    mastery[Master branch y]
    bugbranch[Create bug branch]
    bugfix[Bugfix on branch]
    masterx --> mastery
    masterx --> bugbranch
    bugbranch --> bugfix
    bugfix --> mastery

Github Issues is een minimalistische feature van Github die het mogelijk maakt om zulke bugs op te volgen. Een nieuw issue openen en een beschrijving van het probleem meegeven (samen met stappen om het te reproduceren), maakt een nieuw item aan dat standaard op ‘open’ staat. Dit kan worden toegewezen aan personen, en daarna worden ‘closed’, om aan te geven dat ofwel het probleem is opgelost, ofwel het geen echt probleem was. Issues kunnen worden gecategoriseerd door middel van labels.

Versiebeheer met je favoriete IDE

Sommige IDE’s komen met built-in tools of plug-ins om gemakkelijk gebruik te maken van Version Control en remote repositories. Ik raad je echter aan eerst voldoende te oefenen met de command line tools zodat je altijd weet wat je aan het doen bent. Op die manier ga je beter en vooral sneller problemen kunnen oplossen. Indien je de ‘hard’ way onder de knie hebt, kan je natuurlijk overschakelen naar eender welke tool jij het handigste vindt.

Github Classroom

GitHub Classroom is een hulpmiddel waarmee docenten eenvoudig programmeeropdrachten kunnen beheren en beoordelen via GitHub. Met deze tool kunnen docenten repositories aanmaken voor studenten, opdrachten automatisch toewijzen en versiebeheer integreren in het leerproces. Studenten werken in hun eigen repository, waardoor docenten de voortgang kunnen volgen en feedback kunnen geven op basis van commits en pull requests. Dit vereenvoudigt het beheer van opdrachten en stimuleert het gebruik van professionele ontwikkelpraktijken in het onderwijs.

Opdracht: zie opdrachten