Git 🌙
Chapters ▾ 2nd Edition

1.1 Aan de slag - Over versiebeheer

In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen beginnen met wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af met uit te leggen hoe je Git kan inrichten zodat je ermee aan het werk kunt. Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal gereed zijn om er mee aan de slag te gaan.

Over versiebeheer

Wat is versiebeheer, en waarom zou je je er druk over maken? Versiebeheer is het systeem waarin veranderingen in een bestand of groep van bestanden over de tijd wordt bijgehouden, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van software waarvan de versies beheerd worden, maar in praktijk kan elk soort bestand op een computer aan versiebeheer worden onderworpen.

Als je een grafisch ontwerper bent of websites ontwerpt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het zeer verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Het gebruik hiervan stelt je in staat eerdere versies van bestanden of het hele project terug te halen, wijzigingen tussen twee momenten in de tijd te bekijken, zien wie het laatst iets aangepast heeft wat een probleem zou kunnen veroorzaken, wie een probleem heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra werk met zich mee brengt.

Lokale versiebeheersystemen

De voorkeursmethode van veel mensen voor versiebeheer is om bestanden naar een andere map te kopiëren (en als ze slim zijn, geven ze die map ook een datum in de naam). Deze methode wordt veel gebruikt omdat het zo simpel is, maar het is ook ongelofelijk foutgevoelig. Het is makkelijk te vergeten in welke map je zit en naar het verkeerde bestand te schrijven, of onbedoeld over bestanden heen te kopiëren.

Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ontwikkeld die een simpele database gebruiken om alle veranderingen aan bestanden te beheren.

Een diagram van een lokaal versiebeheersysteem
Figuur 1. Lokale versiebeheer.

Een van de meest populaire gereedschappen voor VCS was een systeem genaamd RCS, wat vandaag de dag nog steeds met veel computers wordt meegeleverd. RCS werkt door verzamelingen van patches (dat zijn de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je een bestand reproduceren zoals deze er uitzag op elk willekeurig moment in tijd door alle patches bij elkaar op te tellen.

Gecentraliseerde versiebeheersystemen

De volgende belangrijke uitdaging waar mensen mee te maken krijgen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging aan te gaan ontwikkelde men Gecentraliseerde Versiebeheersystemen (Centralized Version Control Systems, afgekort CVCSs). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal werkstations die de bestanden daar van ophalen (check out). Vele jaren was dit de standaard voor versiebeheer.

Een diagram van een gecentraliseerd versiebeheersysteem
Figuur 2. Gecentraliseerde versiebeheer.

Deze manier van versiebeheer biedt veel voordelen, zeker ten opzichte van lokale VCSen. Bijvoorbeeld: iedereen weet, tot op zekere hoogte, wat de overige project-medewerkers aan het doen zijn. Beheerders hebben een hoge mate van controle over wie wat kan doen, en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases op elke werkstation.

Maar helaas, deze methode heeft ook behoorlijke nadelen. De duidelijkste is de single point of failure: als de centrale server plat gaat en een uur later weer terug online komt kan niemand in dat uur samenwerken of versies bewaren van de dingen waar ze aan werken. Als de harde schijf waar de centrale database op staat corrupt raakt en er geen backups van zijn, verlies je echt alles; de hele geschiedenis van het project, op de toevallige momentopnames na die mensen op hun eigen computers hebben staan. Lokale VCS systemen hebben hetzelfde probleem: als je de hele geschiedenis van het project op één enkele plaats bewaart, loop je ook kans alles te verliezen.

Gedistribueerde versiebeheersystemen

En hier verschijnen Gedistribueerde Versiebeheersystemen (Distributed Version Control Systems, DVCSs) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar of Darcs) downloaden werkstations niet simpelweg de laatste momentopnames van de bestanden; de hele opslagplaats (de repository) wordt gekopiëerd. Dus als een willekeurige server uitvalt en deze systemen werkten via die server samen dan kan de repository van eender welke werkstation terug worden gekopiëerd naar de server om deze te herstellen. Elke kloon is dus in feite een complete backup van alle data.

Diagram van een gedistribueerd versiebeheersysteem
Figuur 3. Gedistribueerde versiebeheer.

Bovendien kunnen veel van deze systemen behoorlijk goed omgaan met meerdere (niet-lokale) repositories tegelijk, zodat je met verschillende groepen mensen op verschillende manieren tegelijk aan hetzelfde project kan werken. Hierdoor kan je verschillende werkprocessen (workflows) zoals hiërarchische modellen opzetten die niet mogelijk waren geweest met gecentraliseerde systemen.

scroll-to-top