Wat is Git? - De complete gids voor Git

Als je ooit iets hebt gelezen over coderen, programmeren of softwareontwikkeling, dan heb je van Git gehoord.

Deze handige (en gratis) tool is ’s werelds populairste versiebeheersysteem. Het is zo populair dat het door meer dan 90% van de professionele ontwikkelaars wordt gebruikt, om nog maar te zwijgen van professionals in andere vakgebieden.

In veel opzichten is Git praktisch synoniem met versiebeheer. Maar wat is versiebeheer en waarom is het zo belangrijk?

Ga met ons mee voor een deepdive in het Gitverse. We kijken hier van dichtbij naar alles rond Git: wat het is, wie het gebruikt en de geschiedenis ervan.

Wat is Git?

Git is een gedistribueerd versiebeheersysteem (dVCS). Zoals de naam al suggereert, draait versiebeheer om het beheren en bijhouden van verschillende versies van een bepaald project. 

Wat is een versiebeheersysteem (VCS)?

Een VCS volgt en registreert wijzigingen in elk bestand (of een groep bestanden), zodat je later of wanneer nodig specifieke iteraties kunt terughalen. VCS’en worden soms source code management (SCM) of revision control systems (RCS) genoemd.

Versiebeheer maakt het mogelijk dat talloze teamleden samen aan een project werken, zelfs als ze niet in dezelfde kamer of zelfs hetzelfde land zijn. 

Stel bijvoorbeeld dat je songwriter bent. Je werkt thuis hard aan een nieuw nummer dat je hebt geschreven, maar je bent er nog niet helemaal tevreden over. Dus besluit je samen te werken met twee andere songwriters om de stukken aan te pakken die nog werk nodig hebben.

Jij en de twee andere songwriters beginnen de tekst en de partituur te finetunen, ieder onafhankelijk van elkaar. Wanneer de andere muzikanten hun versies van het nummer naar je opsturen, vind je sommige van de veranderingen die ze hebben aangebracht goed, maar niet allemaal.

Stel je nu voor dat je elke wijziging in elke versie van het nummer kunt zien, ze kunt uitproberen om te horen hoe ze klinken en vervolgens de wijzigingen die je goed vindt over versies heen kunt synchroniseren.

Dit is wat Git gebruikers laat doen. Individuen kunnen lokaal aan een project werken (op hun eigen computers), alle wijzigingen die werken opslaan en die vervolgens synchroniseren naar een Git-repository zodat anderen hun nieuwere versie kunnen zien.

Git wordt vaak gezien als een tool voor softwareontwikkeling, wat het ook is, maar het kan worden gebruikt voor versiebeheer (versioning) van elk soort bestand, of het nu om regels code gaat, een designlayout voor een nieuwe website of een lied. 

De voordelen van versiebeheer

Naast dat het een handig hulpmiddel is voor samenwerken, zijn er nog een paar andere voordelen van versiebeheer:

• Toerekenbare wijzigingen. Elke wijziging die wordt aangebracht kan aan een teamlid worden toegeschreven. 
• Diepgaande tracking maakt terugdraaien eenvoudig. Omdat elke wijziging wordt gevolgd, zelfs de hele kleine, is het eenvoudig om indien nodig terug te gaan naar een eerdere versie. Zoals je je kunt voorstellen, is dit een broodnodige functie in softwareontwikkeling.
• Betere organisatie en communicatie. Commitberichten – berichten die je naar het team stuurt waarin je uitlegt waarom je een wijziging hebt aangebracht – bevorderen goede communicatie tussen teamleden. Ze maken het ook een stuk makkelijker als je vergeet welke wijzigingen je in het verleden hebt gemaakt!
• Gelijktijdigheid. In softwareprojecten brengen ontwikkelaars veel wijzigingen aan in de broncode. Meestal werken er tal van ontwikkelaars aan verschillende dingen. De één kan bestaande code aanscherpen voor betere beveiliging, terwijl een ander aan een nieuwe feature werkt. Git stelt deze ontwikkelaars in staat gelijktijdig te werken en helpt conflicten tussen ieders wijzigingen te voorkomen. 
• Branching en mergen. Teamleden kunnen aparte branches aanmaken om aan het project te werken en hun wijzigingen daarna samenvoegen met de mainbranch. Branches zijn tijdelijk en kunnen na een merge worden verwijderd. 

Is Git het enige versiebeheersysteem?

Nee, Git is niet het enige VCS, maar het is wel het populairst en wordt gezien als de de-factostandaard. Andere populaire versiebeheersystemen zijn Fossil, Mercurial en Subversion. 

Er zijn kleine verschillen tussen systemen, onder meer in hoe ze kernfuncties zoals branching en mergen afhandelen, maar in grote lijnen komt het op hetzelfde neer. Het grootste verschil tussen systemen is echter of ze gecentraliseerd of gedistribueerd zijn. 

Gecentraliseerde en gedistribueerde versiebeheersystemen

Zowel gecentraliseerde als gedistribueerde systemen, zoals Git, vervullen dezelfde functie. 

Het belangrijkste verschil is dat gecentraliseerde systemen een centrale server hebben waar teamleden de nieuwste versies van hun werk naartoe pushen. Je kunt het een beetje zien als één centraal project dat iedereen deelt. 

Bij gedistribueerde VCS’en hebben teamleden een lokale kopie (clone) van de volledige projectgeschiedenis op hun eigen apparaat, zodat ze niet online hoeven te zijn om wijzigingen aan te brengen of aan hun code te werken. In plaats van een gecentraliseerde server halen ze deze clone uit een online repository.

Wanneer ontwikkelaars met Git werken, is de clone van het project van elk teamlid een repository die alle wijzigingen sinds het begin van het project kan bevatten.

De geschiedenis van Git

Git werd in 2005 ontwikkeld door de Finse software-engineer Linus Torvalds, die ook wordt gecrediteerd voor de ontwikkeling van de Linux-kernel.

Git werd gecreëerd om in een directe behoefte te voorzien. Voorafgaand aan de uitvinding gebruikten Linux-ontwikkelaars over de hele wereld de propriëtaire software BitKeeper, zelf een dVCS. 

Omdat deze software eigendom was van een bedrijf, zorgde dit voor wrevel onder Linux-ontwikkelaars, van wie de meesten het open-source-ethos hoog in het vaandel droegen. 

In ruil voor het gratis gebruik van de software legde BitMover, het bedrijf achter BitKeeper, de Linux-community beperkingen op. Volgens de Linux Journal was een van die beperkingen dat ze niet aan concurrerende versiebeheerprojecten mochten werken. 

In een stap die misschien onvermijdelijk was, begon een Linux-ontwikkelaar BitKeeper te reverse-engineeren in een poging een open-sourceproduct te creëren. Trouw aan zijn belofte stopte BitMover met het leveren van diensten aan de Linux-kernel en raakte het gedistribueerde ontwikkelsysteem in onzekerheid.

Om dit vraagstuk op te lossen, stopte Torvalds voor het eerst sinds 1991 met werken aan Linux en creëerde Git, waarbij hij enkele maanden na de start van de ontwikkeling al een stabiele versie uitbracht. 

Interessant is dat voordat de Linux-kernel BitKeeper überhaupt adopteerde, ontwikkelaars hun patches (wijzigingen) onafhankelijk naar Torvalds stuurden en hij deze integreerde wanneer dat nodig was. En in 2016, 11 jaar nadat Git was uitgebracht, werd BitKeeper open-source. 

Hoe is Git aan zijn naam gekomen?

Bij Linus Torvalds’ eerste codecommit aan Git in 2005 voegde hij een readme-bestand toe dat enig inzicht geeft in waarom het programma Git heet. Hier is een deel van dat bestand:

Tenzij je de meer gepolijste Global Information Tracker verkiest, is de naam Git een tongue-in-cheekverwijzing naar zijn mogelijkheden of, nou ja, een verondersteld gebrek daaraan. 

De geschiedenis van VCS

Versiebeheersystemen bestaan al langer dan Git of zelfs BitKeeper. Laten we snel een historische tijdlijn doornemen:

• 1972 - SCCS, het eerste VCS, werd gemaakt door Bell Labs; dit lijkt weinig op de systemen van vandaag.
• 1982 - Revision Control System (RCS) wordt ontwikkeld door een informaticus aan de Purdue University.
• 1986 - Concurrent Versions System (CVS) wordt ontwikkeld. Dit is het eerste VCS met een gecentraliseerde repository die toegankelijk is voor meerdere gebruikers.
• 1995 - Perforce, een nog steeds populair VCS, wordt ontwikkeld.
• 2000 - Een geavanceerder systeem genaamd Subversion (ook wel SVN) verschijnt op het toneel. Eveneens BitKeeper, een van de eerste dVCS’en en het systeem dat gedistribueerde systemen populariseerde.
• 2005 - Git wordt uitgevonden en wordt al snel de go-to voor ontwikkelaars wereldwijd. 

Git en GitHub, versiebeheer en repositories

Git en GitHub zijn complementaire technologieën. Git is een versiebeheersysteem, terwijl GitHub een cloudgebaseerde hostingsdienst is die teams helpt hun repositories te beheren. 

GitHub werd in 2008 ontworpen om samenwerken met Git makkelijker te maken, iets waar het software-as-a-service (SaaS)-platform in uitblonk en waarmee het uiteindelijk miljoenen gebruikers wereldwijd aantrok. 

Naast de standaardfunctie voor versiebeheer van Git heeft GitHub eigen features zoals bugtracking, taakbeheer en continuous integration (CI). GitHub werkt met een freemiummodel; gebruikers hebben gratis toegang tot veel functies maar moeten voor een premiumabonnement betalen om alle features te ontgrendelen. GitHub is sinds 2018 eigendom van Microsoft. 

GitHub is niet de enige repositoryhost, maar met miljoenen gebruikers en honderden miljoenen projecten die op het platform vertrouwen is het met afstand de populairste ter wereld. Je vindt er genoeg grote namen, waaronder DataCamp. 

Concurrerende diensten zijn onder meer GitLab, een volledig vrije en open-sourceservice die is ontworpen voor Git, en Bitbucket, dat zowel Git- als Mercurial-codemanagement ondersteunt.

We noemden eerder al dat Git en versiebeheer niet alleen voor coderen en softwareontwikkeling zijn, en hetzelfde geldt voor GitHub, al is dat laatste niet geoptimaliseerd voor niet-codeprojecten.

Git is meer dan een tool voor softwareontwikkeling

Git kan worden gebruikt voor elk soort samenwerkingsproject waarbij versiebeheer belangrijk is, bijvoorbeeld het schrijven van een uitgebreide handleiding of zelfs het maken van kerkmuziek (dat laatste is een echt project dat je kunt bekijken op GitHub)

Hoewel het primair wordt geassocieerd met het pure codeerwerk van softwareontwikkeling, gebruiken mensen in aanverwante vakgebieden Git regelmatig. Datawetenschappers en analisten zijn daar een goed voorbeeld van; deze professionals hebben een manier nodig om de code te beheren die hun werk ondersteunt, en Git biedt precies dat. 

Hier bij DataCamp leren we mensen de tools en technologieën die ze nodig hebben om met data te werken, waaronder Git. Onze reeks meeslepende en boeiende Git-cursussen vind je hier.

Waarom is Git zo populair?

Git is om een aantal redenen populair, niet in de laatste plaats omdat het gratis en open-source is.

• Snelheid. Git is snel, zeker als je bedenkt dat ontwikkelaars een hele repository branch’en en mergen. Omdat iedereen in het team een eigen lokale kopie heeft, hoeft niet voor elke kleine wijziging op een server te worden gewacht.
• Fijngranulaire tracking van wijzigingen. Git biedt ongelooflijk gedetailleerde versiegeschiedenis; zelfs de kleinste wijzigingen worden gecommit, en ontwikkelaars kunnen een tijdgestempelde opmerking achterlaten waarin ze uitleggen waarom ze elke wijziging hebben aangebracht.
• Offline werken. Met lokale kopieën van de hele repository hoeven gebruikers niet online te zijn totdat ze klaar zijn om hun wijzigingen te committen. 
• Alomtegenwoordigheid. Tegenwoordig wordt Git zo veel gebruikt dat zijn alomtegenwoordigheid de populariteit verder voedt. Meer dan 90% van de ontwikkelaars gebruikt Git, en er is weinig reden voor een bedrijf om een andere tool te gebruiken als het weet dat alle ontwikkelaars met Git vertrouwd zijn.
• Samenwerking. Git maakt samenwerken mogelijk en vereenvoudigt het mergen van verschillende versies van hetzelfde project, terwijl het de kans op conflicten minimaliseert. Met de toevoeging van GitHub hebben ontwikkelaars een wendbaar samenwerkend code-ecosysteem dat hun werk ondersteunt.

Hoe werkt Git?

Om de kracht en efficiëntie van Git echt te begrijpen, moeten we in enkele technische details duiken. Hier volgt een overzicht van hoe Git werkt:

1. Repository (repo). Een Git-repository is een map waarin alle bestanden voor een bepaald project zijn opgeslagen. Het bevat alle revisies en de geschiedenis van het project. Wanneer je Git in een map initialiseert (git init), wordt het een repository.
2. Commits. Elke wijziging of set wijzigingen die je in Git afrondt, heet een commit. Elke commit heeft een unieke ID (een SHA-1-hash) waarmee Git de wijzigingen en de volgorde waarin ze zijn gemaakt kan bijhouden.
3. Staging area. Voordat je wijzigingen definitief maakt met een commit, “stage” je ze eerst. De staging area is als een kladruimte waarin je je wijzigingen voorbereidt voordat je ze commit. Om bestanden aan de staging area toe te voegen, gebruik je het commando git add
4. Branches. Git laat je meerdere ontwikkellijnen maken via branches. De standaardbranch heet master. Als je een feature wilt ontwikkelen of een bug wilt fixen, kun je een nieuwe branch aanmaken (git branch <branch-name>) om je wijzigingen te isoleren zonder de hoofdlijn van de ontwikkeling te beïnvloeden.
5. Mergen. Als je klaar bent met je wijzigingen op een branch, kun je die wijzigingen terug samenvoegen in de master-branch (of een andere branch) met het commando git merge.
6. Remote repositories. Terwijl je lokaal op je machine werkt, kun je met Git ook verbinding maken met remote repositories met het commando git remote. Dit is vooral handig voor samenwerking. Zoals besproken is de meest gangbare remote repository GitHub.
7. Push en pull. Eenmaal verbonden met een remote repository kun je je wijzigingen ernaartoe pushen, zodat anderen je code kunnen zien en eraan kunnen samenwerken. Evenzo kun je wijzigingen van een remote repository pullen om je lokale versie bij te werken met de laatste updates.
8. Fetch. Vergelijkbaar met pull stelt het commando git fetch je in staat om updates van een remote repository op te halen, maar het voegt de wijzigingen niet automatisch samen in je huidige branch. Dit geeft je de flexibiliteit om wijzigingen te beoordelen voordat je ze integreert.
9. Clone. Als je een kopie wilt hebben van een bestaande Git-repository, gebruik je het commando git clone. Dit maakt een nieuwe map op je machine met alle bestanden en de volledige geschiedenis van de repository.
10. Conflictoplossing. Soms kunnen er conflicten ontstaan wanneer meerdere mensen aan hetzelfde stuk code werken. Git heeft ingebouwde mechanismen om deze conflicten te markeren, zodat ontwikkelaars ze handmatig kunnen oplossen voordat ze een merge afronden.
11. Log. Om de geschiedenis van je commits te bekijken, biedt Git het commando git log. Dit toont een lijst met commits, hun unieke ID’s en de bijbehorende berichten.

Inzicht in deze technische details vormt de basis voor werken met Git. Naarmate je vertrouwd raakt met deze concepten en commando’s, ga je de flexibiliteit, kracht en efficiëntie waarderen die Git aan versiebeheer toevoegt.

Wil je Git gaan gebruiken?

Git is ’s werelds populairste gedistribueerde VCS en het heeft de manier waarop softwareontwikkelaars en mensen in aanverwante vakgebieden hun projecten beheren, ingrijpend veranderd.

Bedrijven van Google tot Netflix en talloze anderen daartussen gebruiken Git als standaardonderdeel van hun techstack. Git is zo alomtegenwoordig dat je bij elk software- of coderelated project kunt aannemen dat Git deel uitmaakt van het proces. 

Het is ook een onmisbare skill voor mensen die met data werken, zoals data-analisten en -wetenschappers. We hebben tenslotte een manier nodig om de code te versioneren die ons helpt data om te zetten in inzichten en softwaretools te bouwen die ons werk ondersteunen.

Git is de de-factostandaard voor VCS, en als je in de IT of een aanpalend vakgebied wilt werken, is het een must-have vaardigheid. Hoewel Git niet bepaald bekendstaat om zijn eenvoud, is het eenvoudig genoeg om de basis onder de knie te krijgen en je kennis uit te bouwen terwijl je je door het Gitverse beweegt. 

DataCamp kan helpen. Onze Introduction to Git-cursus is ontworpen om je de essentie van Git op een leuke en boeiende manier te leren. Als je op snelheid bent, kun je overwegen om GitHub-gecertificeerd te worden om je skills te laten zien. 

Ontdek waarom meer dan negen miljoen learners wereldwijd dol zijn op DataCamp en schrijf je vandaag nog in voor je eerste Git-cursus!