View profile

DEF_verslag_6c-inclusief-correcties-ingrid_FINAL_V22.docx

Jos van Essen
Jos van Essen
Op de middelbare school ontving ik dit soort documenten in m'n mailbox zodra ik met klasgenootjes samen moest werken aan verslagen. Herkenbaar? Iedereen schreef een hoofdstuk, en de arme ziel die alles zou samenvoegen eindigde in een hel van Word documenten, verschillende en correcties.
In deze nieuwsbrief wil ik het hebben over versiebeheer.
Ieder team dat zichzelf enigzins serieus neemt en aan professionele software werkt gebruikt versiebeheer. Hiermee voorkom je dat je elkaars code overschrijft, of stuk maakt. Hoe groter je team, hoe urgenter de noodzaak van versiebeheer. Er zijn verschillende soorten, maar de belangrijkste om te kennen is Git.
Git zorgt er voor dat alle code op een centrale plek wordt opgeslagen en dat wijzigingen in de code worden bijgehouden. Een leuk weetje: Linus Torvalds, de bedenker van Linux vond Git uit toen hij probeerde samen te werken met meerdere ontwikkelaars aan Linux. Dit mondde uit in een chaos van dubbele code en om dit op te lossen bouwde hij Git.
Starten met versiebeheer is eigenlijk heel simpel. Je kiest waar je je code wil onderbrengen, bijvoorbeel Github, Gitlab of Bitbucket en daar maak je een project aan, genaamd een repository. In deze repository sla je code op.
Je collega’s kunnen deze code vervolgens vanuit de centrale plek downloaden en lokaal (dus op hun eigen computers) ontwikkelen. Wanneer ze klaar zijn met een specifiek stukje kunnen ze de code eerst ‘committen’ en vervolgens pushen naar de centrale repository. Git houdt vervolgens bij of er overlap ontstaat met andere code. Wanneer dit het geval is dan vraagt Git om dit op te lossen.
Er zijn vrij veel technische details en manieren van werken denkbaar om te werken met Git en repositories. Dit is vaak een team-aangelegenheid. Zo kun je er voor kiezen om in meerdere ‘branches’ te werken: aftakkingen van de bestaande code. Wanneer een feature af is kan deze als aftakking weer worden samengevoegd met de belangrijkste stam: de master of main.
Een veelvoorkomend scenario is bijvoorbeeld:
Developer X gaat werken aan een nieuwe login flow waarbij je ook met Google en Facebook kunnt inloggen. Hij maakt een nieuwe branch aan en werkt hier een aantal dagen in, tot de functionaliteit klaar is. Om de functionaliteit te testen wil hij deze doorzetten naar acceptatie. Hij maakt een Pull Request om zijn branch te ‘mergen’ met de acceptatie-branch. Wanneer dit zonder problemen is gelukt dan is zijn code aanwezig in de acceptatie-branch en kan deze weer later worden samengevoegd met de ‘master’ of ‘main’ branch.
Git wordt door sommige ontwikkelaars ervaren als een noodzakelijk, maar vervelend fenomeen waar ze liever niet mee bezig zijn. De kans op merge-conflicten waarbij code niet kan worden samengevoegd is immers altijd aanwezig, en soms is het ook niet meteen duidelijk hoe dit komt. Toch is het een noodzakelijk kwaad: zonder versiebeheer zou er enorm veel code verloren gaan, en zou ook het veilig ‘deployen’ van code een stuk lastiger worden: het daadwerkelijk versturen van de code naar de server. Hierover volgende week meer.

Did you enjoy this issue? Yes No
Jos van Essen
Jos van Essen

JSON, API's, webtokens, CI deployments, JavaScript, Tag Manager: we horen allemaal regelmatig termen voorbij komen waarvan we niet 100% zeker weten of we het ook daadwerkelijk begrijpt. Deze nieuwsbrief laat een licht schijnen op deze materie: tech voor op het web uitgelegd

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.