1.2 Aan die slag - Wat is Git?

Die grootste verskil tussen Git en enige ander VCS (insluitend Subversion en ensovoorts) is die manier waarop Git oor sy data dink. Konseptueel stoor die meeste ander stelsels inligting as 'n lys van veranderinge per lêer. Hierdie ander stelsels (CVS, Subversion, Perforce, Bazaar, ensovoorts) dink aan die inligting wat hulle stoor as 'n groep lêers en die veranderinge wat oor tyd aan elk van hierdie lêers aangebring is (dit word gewoonlik beskryf as delta-gebaseerde weergawestelsels).

Git dink en stoor data nie op hierdie manier nie. Git se kyk op data kan eerder verduidelik word as 'n reeks momentopnames (snapshots) van 'n miniatuur-lêerstelsel. Elke keer as jy "'n commit" doen (die status van jou projek in Git stoor), neem Git as 't ware 'n foto van die toestand van al jou lêers op daardie oomblik en stoor 'n verwysing na daardie momentopname. Uit oogpunt van doeltreffendheid stoor Git nie ongewysigde lêers elke keer weer nie, maar slegs 'n skakel na die vorige identiese lêer wat dit reeds gestoor het. Git beskou data meer as 'n stroom van momentopnames.

Dit is 'n belangrike onderskeid tussen Git en byna alle ander VCSen. Dit het Git gedwing om byna elke aspek van weergawestelsels te heroorweeg, terwyl die meeste ander stelsels dit van vorige generasies oorgeneem het. Dit maak van Git eerder 'n soort mini-lêerstelsel met 'n paar ongelooflik kragtige gereedskap bo-op, in plaas van slegs 'n weergawestelsel. Ons sal 'n paar van die voordele wat jy kry as jy op hierdie manier oor data dink, ondersoek wanneer ons vertakkings (branching) toelig in Git Branching.

Vir die meeste handelinge in Git is slegs plaaslike lêers en hulpmiddels nodig – normaalweg is geen inligting van 'n ander rekenaar in jou netwerk nodig nie. As jy gewoond is aan 'n CVCS, waar die meeste handelinge vertraag word deur netwerkvertraging, sal hierdie aspek van Git jou laat dink dat die gode van spoed Git met bonatuurlike kragte geseën het. Omdat jy die hele geskiedenis van die projek op jou plaaslike hardeskyf het, lyk die meeste aksies byna onmiddellik.

Byvoorbeeld: om die geskiedenis van jou projek te deurloop, hoef Git nie by 'n afgeleë rekenaarbediener in te skakel om die geskiedenis te gaan haal en vir jou te vertoon nie; dit lees dit bloot direk vanaf jou plaaslike databasis. Dit beteken dat die projekgeskiedenis byna oombliklik vir jou beskikbaar is. As jy die veranderinge wil sien tussen die huidige weergawe van 'n lêer en die lêer van 'n maand gelede, kan Git die lêer van 'n maand gelede opsoek en plaaslik 'n verskilberekening doen, in plaas daarvan om 'n rekenaarbediener te vra om dit te doen, of om 'n ouer weergawe van die lêer vanaf 'n afgeleë rekenaarbediener te moet aflaai om dit plaaslik te doen.

Dit beteken ook dat daar baie min is wat jy nie kan doen as jy vanlyn is of nie op 'n VPN is nie. As jy in 'n vliegtuig of trein is en jy wil 'n bietjie werk, kan jy vrolik voortgaan met "'n commit" (na jou plaaslike kopie, onthou?). Wanneer jy weer by 'n netwerkverbinding uitkom, kan jy dit oplaai. As jy by die huis kom en jou VPN-kliënt werk nie behoorlik nie, kan jy steeds voortwerk. In baie ander stelsels is dit óf onmoontlik óf baie onaangenaam. In Perforce, byvoorbeeld, kan jy nie veel doen as jy nie met die rekenaarbediener verbind is nie; met Subversion en CVS kan jy lêers wysig, maar jy kan nie "'n commit" na jou databasis maak nie (omdat die databasis vanlyn is). Dit lyk dalk nie na 'n groot saak nie, maar jy sal dalk verbaas wees watter groot verskil dit kan maak.

Alles in Git kry 'n kontrolesom (checksum) voordat dit gestoor word en daarna word daar slegs na daardie kontrolesom verwys. Dit beteken dat dit onmoontlik is om die inhoud van enige lêer of gids te verander sonder dat Git daarvan weet. Hierdie funksionaliteit is op die laagste vlakke van Git ingebou en staan sentraal in sy filosofie. Jy kan nie inligting tydens oordrag verloor of lêerkorrupsie kry sonder dat Git dit kan opmerk nie.

Die meganisme wat Git vir hierdie kontrolesom gebruik, word 'n SHA-1-hash genoem. Dit is 'n string van 40 karakters, bestaande uit heksadesimale karakters (0–9 en a–f) en word bereken gebaseer op die inhoud van 'n lêer of gidsstruktuur in Git. 'n SHA-1-hash lyk soos volg:

Jy sal hierdie hash-waardes oral in Git teëkom omdat dit so baie daarvan gebruik maak. Trouens, Git stoor alles in sy databasis nie onder 'n lêernaam nie, maar deur die hash-waarde van die inhoud as sleutel te gebruik.

Byna alles wat jy in Git doen, lei tot die toevoeging van data in die Git-databasis. Dit is baie moeilik om die stelsel iets te laat doen wat nie ongedaan gemaak kan word nie, of om data te laat wis op enige manier. Soos met enige VCS kan jy veranderinge verloor of deurmekaar krap as jy dit nog nie gecommit het nie, maar sodra jy 'n momentopname in Git gecommit het, is dit baie moeilik om daardie data te verloor, veral as jy jou databasis gereeld na 'n ander bewaarplek (repository) opstoot (met push).

Dit maak die gebruik van Git so plesierig omdat ons weet dat ons kan eksperimenteer sonder die gevaar om dinge heeltemal op te foeter. Vir 'n meer diepgaande kyk na hoe Git data stoor en hoe jy data wat verlore lyk kan terughaal, sien Dinge ongedaan maak.

Let nou goed op – dit is die belangrikste ding om van Git te onthou as jy wil hê die res van jou leerproses moet glad verloop. Git het drie hoof-toestande waarin lêers kan verkeer: gewysig (modified), voorbereid (staged), en gecommit (committed):

Dit bring ons by die drie hoofonderdele van 'n Git-projek: die werk-boom (working tree), die voorbereidingsarea (staging area), en die Git-gids (Git directory).

Die werk-boom is 'n enkele uitklok van een weergawe van die projek. Hierdie lêers word uit die saamgeperste databasis in die Git-gids gehaal en op die hardeskyf geplaas sodat jy dit kan gebruik of wysig.

Die voorbereidingsarea is 'n lêer, gewoonlik vervat in jou Git-gids, wat inligting stoor oor wat in jou volgende commit sal ingaan. Die tegniese naam in Git-vaktaal is die “index”, maar die uitdrukking “voorbereidingsarea” werk net so goed.

Die Git-gids is waar Git die metadata en objekdatabasis vir jou projek stoor. Dit is die belangrikste deel van Git, en dit is wat gekopieer word wanneer jy 'n bewaarplek vanaf 'n ander rekenaar kloon (clone).

Die basiese Git-werkstroom lyk ongeveer soos volg:

As 'n spesifieke weergawe van 'n lêer in die Git-gids is, word dit as gecommit beskou. As dit gewysig is en by die voorbereidingsarea gevoeg is, is dit voorbereid (staged). En as dit verander is sedert dit uitgeklok is, maar nie voorberei is nie, is dit gewysig (modified). In Git Basics sal jy meer leer oor hierdie toestande en hoe jy óf daarvan gebruik kan maak óf die voorbereidingsdeel heeltemal kan oorslaan.