Git is een gedistribueerd versiebeheersysteem. Door Git als versiebeheersysteem te gebruiken, is het mogelijk om tegelijkertijd wijzigingen aan een codebase te maken zonder je zorgen te hoeven maken of code van een ander overschreven wordt.
Geschiedenis van Git
Git is ontstaan tijdens de ontwikkeling van de Linux kernel. De kernel van Linux is ontwikkeld door Linus Torvalds en door de open source community. In 2002 maakte de groep die aan de Linux kernel werkte gebruik van het versiebeheersysteem BitKeeper. Software die voor iedereen in de community gratis te gebruiken was. Drie jaar later, in 2005, ontstond er onenigheid tussen de Linux kernel groep en het bedrijf achter BitKeeper waarna Linus en de groep gestart zijn met het ontwikkelen van de tool Git.
Volgens Linus en de groep waren er een aantal eisen waaraan Git moest voldoen:
- Snelheid
- Simpel in gebruik zijn
- Non-linear development (parallelle branches)
- Volledig gedistribueerd
- Om kunnen gaan met grote projecten (zoals de Linux kernel)
Introductie Git
Zoals ik eerder al schreef is Git een gedistribueerd versiebeheersysteem. Dit houdt in dat de complete codebase, inclusief volledige geschiedenis van versies en code, op de computer van de ontwikkelaar staat. In technische termen wordt dit ook wel mirorring genoemd. Door de offline functionaliteiten van Git is het programma in elke situatie te gebruiken, zelfs wanneer je in het vliegtuig zonder internet zit. Soms kan het zijn dat internet langzaam is, door de offline functionaliteit die Git biedt kun je alsnog snel werken.
Git werkt met snapshots van een project. Iedere commit zorgt voor een “foto” van hoe je bestanden in de huidige staat eruitzien en slaat deze “foto” op als een snapshot. Deze snapshot wordt opgeslagen in de .git omgeving. Git werkt zo efficiënt mogelijk en slaat alleen gewijzigde bestanden op en niet de ongewijzigde bestanden, zodat er geen duplicaten ontstaan.
Figuur 2 toont vijf versies van een project. In deze versies zijn een aantal bestanden te zien (versie 1 heeft bestanden A, B en C). Vanaf versie 2 heeft Git een snapshot van versie 1 gemaakt. In versie 2 zijn twee bestanden gewijzigd en heten nu A1 en C2, maar bestand B is ongewijzigd gebleven. En in versie 3 is bestand B ook intact gebleven, maar er is wel meegenomen naar de volgende versie.
Doordat Git met snapshots werkt lijkt het op een mini-filesysteem waar verschillende handelingen op zijn gebouwd.
Integriteit van Git
Alles binnen Git wordt voorzien van een checksum voordat data is opgeslagen. Hierna verwijst de checksum naar het specifieke stuk data. Een checksum zorgt voor zekerheid dat een kopie van data authentiek en volledig is. Git zorgt ervoor dat er geen informatie of data verloren gaat in het proces. Zodra dit wel het geval is detecteert Git dit onmiddellijk. Git slaat de checksum van de data op en niet de bestandsnamen zelf.
De checksum die opgeslagen wordt, ziet er als volgt uit: 8ff6ec521ab2e3116efeab623384c231c4941e82. Git laat de eerste zeven karakters van de checksum zien. In het geval van de voorbeeld checksum: 8ff6ec5. Dit is dus de referentie naar de bestandsversie.
Bestand statussen
Een bestand binnen Git heeft verschillende statussen. Deze statussen zijn: het bestand is aangepast, het bestand is gemarkeerd om opgeslagen te worden en het bestand is veilig opgeslagen. De Git termen hiervoor zijn: modified, staged en commited. Naast deze statussen kent Git ook drie omgevingen. Deze omgevingen worden door Git gebruikt om de bestanden door een bepaalde flow te begeleiden. Deze omgevingen zijn: working directory, staging area en de repository (figuur 3).
In figuur 3 zijn de drie statussen van een bestand toegelicht:
- Stage Fixes – Dit is de modified status. Bij status modified betekent het dat de data gewijzigd is, maar nog niet committed is naar de database. De bestanden in deze status zijn gemarkeerd als staged. Dit is de status na modified. Nu de bestanden gemarkeerd zijn, worden de bestanden bij de volgende commit meegenomen.
- Commit – bij status comitted is de data veilig opgeslagen in de lokale database van Git.
In figuur 3 staan ook de omgevingen drie omgevingen toegelicht:
- Working directory – is de kopie van het project waaraan een ontwikkelaar op zijn of haar computer werkt. De kopie komt uit de database uit de Git directory en wordt verplaatst naar de computer om te gebruiken of om te wijzigen.
- Staging area – is een bestand dat in de Git directory is opgenomen. In dit bestand staat de informatie over wat er in de volgende commit gaat plaatsvinden.
- Git directory –is het hart en brein van Git. In deze folder staan de metadata en geschiedenis database van alle commits.
Deze bestandslevenscyclus en omgevingen zijn kort wat codebeheer met Git inhoudt.
Conclusie
Git kan in het begin gecompliceerd ogen, maar de ervaring leert dat door het gebruik van deze krachtige versiebeheertool de applicatieontwikkeling en het beheren van documentatie verbeterd kunnen worden. Git kan bij een project door meerdere developers tegelijk gebruikt worden.
Bij Delta-N gebruiken wij Git voor onze software development projecten. Zodat wij als team gemakkelijk code kunnen samenvoegen, beheren en samen kunnen werken aan een codebase. Mocht je iets door het lezen van de blog meer willen weten over Git? Stuur mij een e-mail via johnl[a]delta-n.nl.
Maakt u nog geen gebruik van Git, lees dan ook het blog Overstappen naar Git.
John Lokerse, Developer
Referenties
1. GIT Illustrated Cheatsheet — Illustrated GIT 1.0 documentation. (2019). Overgenomen van: https://illustrated-git.readthedocs.io/en/latest/.
2. Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Berkeley, CA: Apress.
2. Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Berkeley, CA: Apress.
