I’m very happy with git. It works remarkably well for the kernel and is still meeting all my expectations. What I find interesting is how it took over so many other projects, too. Surprisingly quickly, in the end. There is a lot of inertia in switching source control systems; just look at how long CVS and even RCS have stayed around, but at some point git just took over.
—Linus Torvalds (maker van Linux en Git) als antwoord op de vraag: “Has Git lived up to your expectations? How is it working today in your estimation? Are there any limitations?”

Versiecontrole met Git en Github

Rol van dit hoofdstuk

Vanaf dit deel (voor heel module 2) gebruiken we Git als versiecontrolesysteem voor onze code. Je maakt oefeningen en de uiteindelijke grote opdracht voor deze module (een JS app) in GitHub Classroom. Via GitHub Pages automatiseer je het bouwen van deze app.

Git kan best moeilijk zijn. Ik ontsteek nog altijd een kaars, brand wierook en prevel een gebedje vooraleer ik me waag aan één van de gevorderde acties in Git. We zullen ons in dit stukje beperken tot basisgebruik. We werken immers voorlopig nog als enige developer aan onze code en dus is het moeilijkste stukje van Git (samenwerken, branching, merge, …) niet nodig.

Maar een kaarsje zou ik toch in de buurt houden …

Wat is Git?

Git is een versiecontrolesysteem (VCS). Het is ontworpen door Linus Torvalds en is momenteel zonder twijfel het meest gebruikte systeem in de softwarewereld.

Git probeert een oplossing te bieden voor twee problemen:

De nood aan bijhouden van verschillende versies

Herken je de volgende figuur? Ongetwijfeld heb je ooit iets dergelijks gedaan om toch maar verschillende versies van een project bij te houden.

allemaal mapjes met verschillende versies van dezelfde code

Dit is een onhoudbare situatie. Het is onmogelijk om te weten welke versie de laatste is, welke versie de juiste is, welke versie onvolledig is, enzovoort. Het is ook onmogelijk om te weten welke wijzigingen er gebeurd zijn tussen de verschillende versies.

Git is een systeem dat toelaat om alles wijzigingen te documenteren (met zogenaamde ‘commits’) en zo de geschiedenis van de code te reconstrueren zodat je kan teruggaan naar een welbepaalde versie.

De nood aan samenwerking

Stel je voor dat je met een team van 5 (of 50, 500, …) developers aan een project werkt. Iedereen werkt aan een stukje van de code. Hoe zorg je ervoor dat iedereen aan de juiste versie werkt? Hoe zorg je ervoor dat iedereen de wijzigingen van de anderen kan zien? Hoe zorg je ervoor dat iedereen zijn wijzigingen kan delen met de anderen?

Git is een systeem dat toelaat om wijzigingen van verschillende developers samen te brengen in één codebase. Elke developer kan aan één aspect van de code werken en als dit voldoende getest is, beslissen om dit toe te voegen aan de codebase (met een ‘merge’ of een ‘pull request’).

Git in twee minuten

Het volgend filmpje legt Git uit in twee minuten. Volgende begrippen worden vermeld:

How Git works: explained in 4 minutes

Toch nog een tweede kort filmpje dat (heel visueel) wat meer in detail gaat en al wat meer technische termen gebruikt. Die termen leren we later gebruiken, maar het is wel handig dat je ze al eens gehoord hebt, met een mooie figuur erbij als illustratie. Dus geen paniek als je niet alles begrijpt, dat komt later wel. Volgende begrippen worden vermeld:

Git installeren

Git is een command line tool. Dat betekent dat je het moet installeren en gebruiken via de terminal. Er bestaan ook grafische tools die je kunnen helpen, maar het is belangrijk dat je de commando’s kent.

Git is een open source project en is dus gratis te gebruiken. Je kan het downloaden van de officiële website: git-scm.com.

Tijdens de installatie kan je een aantal opties kiezen. De standaard instellingen zijn meestal goed. Als je niet weet wat je moet kiezen, kan je de standaardinstellingen behouden.

Open een nieuwe terminal in Visual Studio Code via het menu ‘Terminal’. Zorg er wel voor dat dit een ‘bash’ terminal is, zie figuur hieronder.

Wie weet is Git al geïnstalleerd op je systeem? Typ in dit terminalvenster git --version. Als je een versienummer krijgt, hoef je niets te doen. Als je een foutmelding krijgt, moet je Git installeren. Enkele tips voor de installatie:

Na de installatie moet je nog een kleine configuratiestap uitvoeren. Voor die configuratie is het voldoende om je naam en e-mailadres in te stellen via

git config --global user.name "Jouw naam"
en
git config --global user.email "voornaam.familienaam@student.ucll.be"

Commits in een lokale git repository

Een Git repository is een map waarin Git de geschiedenis van je code bijhoudt. Je kan een map omtoveren tot een Git repository door in die map het commando git init uit te voeren. Dit commando maakt een verborgen map aan in je map met de naam .git. In deze map houdt Git alle informatie bij over de geschiedenis van je code.

Volg nu de stappen in het volgende filmpje om een lokale Git repository te maken en je eerste commits te doen. Volgende begrippen worden vermeld:

GitHub

GitHub is een online platform waarop je je Git repositories kan delen met anderen. Het is een soort van sociale media voor developers. Je kan er code delen, code van anderen bekijken, code van anderen gebruiken, …

Maak een account op GitHub. Volg de stappen in ‘Signing up for a new personal account’. Gebruik zeker je UCLL-mailadres. Mogelijk komt hier wel één en ander bij kijken, zoals bvb 2-factor-authenticatie.

Als je GitHub-account aangemaakt is, moet je die natuurlijk testen. Dat kan m.b.v. de locale repo die je hierboven maakte. Volg hiervoor onderstaand filmpje en probeer alles zelf uit. Je publiceert je locale repo naar GitHub en gebruikt sync (of push en pull) om code te synchroniseren tussen je local en remote repository.

GitHub Pages

GitHub Pages is een dienst van GitHub die het mogelijk maakt om een website te hosten op GitHub. Je kan een website maken in HTML, CSS en JavaScript en deze publiceren op GitHub Pages.

In module 1 (HTML en CSS) maakte je als hoofdopdracht een statische site van vier pagina's. Je ontwikkelde meestal op je lokale machine, maar af en toe is het toch nodig om het resultaat online te bekijken (bvb. om te testen op een echte smartphone en niet via de simulatie van de Responsive Design Mode van de browser).

Via FTP kon je de gewijzigde bestanden op de server plaatsen. Niet echt moeilijk, maar toch weer een extra stap. In dit deel wordt het mogelijk om bij elke commit die je doet in je repo automatisch je statische site te bouwen via de online dienst GitHub Pages.

Je maakte hierboven al een fantastische webpagina in je local repo. Die werd vervolgens gesynchroniseerd met je remote GitHub repo. De volgende video toont nu de extra stap: GitHub Pages instellen zodat je bij elke commit een automatische build and deploy stap krijgt.

GitHub Classroom

Voor module 2 (JS) gaan we gebruik maken van Git, GitHub en een initiatief van GitHub voor onderwijs: GitHub Classroom.

Module 2 leidt uiteindelijk naar een JS-app van twee pagina's die gebruik maakt van DOM-manipulatie, events, modules, localStorage, … Al deze topics komen aan bod in deze cursussite in de volgende hoofdstukken. We stellen voor om deze leerstof in twee stappen te verwerken:

  1. Bekijk een hoofdstuk in de cursustekst. Bij elk hoofdstuk hoort een kleine oefening waarvan de bijhorende opgave op Toledo een link is naar een Classroom Assignment in GitHub. Volg de stapjes zoals uitgelegd in onderstaande video om deze Assignment te forken, lokaal te maken en te testen en dan te committen en synchroniseren met je remote repository die bij deze opdracht hoort. Commit early and often (maar niet meer dan tien keer per uur)!
  2. In elk hoofdstuk worden stappen gezet die uiteindelijk leiden naar een grote afgewerkte JS-app die als voorbeeld wordt uitgewerkt. Zet diezelfde stappen nadat je de oefening maakte uit stap 1. Maak dus je eigen versie van de citaten-app, met de filmpjes als leidraad.

Het filmpje toont hoe ik de eerste assignment zou oplossen. De link naar deze assignment vind je op Toledo. Je krijgt startcode, die in de praktijk vaak heel erg beperkt is en soms zelfs enkel bestaat uit een readme.md markdown bestand. Dat is voor deze opdracht effectief zo. Dit readme bestand geeft enkele instructies: een HTML-bestand, een klein beetje CSS en één afbeelding. De video toont:

  1. de assignment aanvaarden (een zogenaamde fork) op GitHub Classroom;
  2. de opdracht klonen naar een lokale repo;
  3. lokaal werken, committen en testen;
  4. GitHub Pages instellen voor je online repo;
  5. enkele keren synchroniseren en telkens nakijken of je GitHub Pages aangepast wordt.

Vergeef je me het geworstel met accounts? Ik gebruik hier een aparte GitHub account om te testen, maar Visual Studio Code stond er toch op om mijn gewone accountgegevens in te vullen. Uiteindelijk komt het wel allemaal in orde …

Feedback op Toledo-opdrachten via GitHub Classroom

De Toledo-opdrachten die je maakt in deze module (JS) worden ingediend via GitHub Classroom. Je maakt een kopie van de opdracht (een fork) en werkt deze lokaal uit. Je commit vaak en synchroniseert (via push) je lokale repository met de remote repository op GitHub. De docent kan dan je code bekijken en feedback geven.

Het volgende filmpje simuleert hoe de communicatie tussen student en docent kan gaan via GitHub Classroom. De linkerhelft van het scherm is de browser van de student, de rechterkant toont de GitHub van de docent.

De situatie is een beetje kunstmatig, want je maakt de aanpassingen in jouw code altijd via VS Code. Dat vergt van mij echter wat wisselingen met accounts, wat niet altijd vlot loopt. Daarom kies ik er hier in deze instructievideo voor om het coderen van de student te doen in GitHub zelf, wat natuurlijk in het echt super onpraktisch zou zijn!

De video toont volgende stappen: