-
1. Aan die slag
- 1.1 Oor Weergawebeheer
- 1.2 Wat is Git?
- 1.3 Die Opdragreël
- 1.4 Git Installeer
- 1.5 Git klaarmaak vir eerste gebruik
- 1.6 Hulp Verkry
- 1.7 Opsomming
-
2. Git Basics
-
3. Git Branching
-
4. Git on the Server
- 4.1 Die Protokolle (The Protocols)
- 4.2 Git op 'n Bediener kry (Getting Git on a Server)
- 4.3 Jou Publieke SSH-sleutel Genereer (Generating Your SSH Public Key)
- 4.4 Die Bediener Opstel (Setting Up the Server)
- 4.5 Git Daemon
- 4.6 Slim HTTP (Smart HTTP)
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Derdeparty-gasheuroplossings (Third-Party Hosting Solutions)
- 4.10 Summary
-
5. Distributed Git
-
6. GitHub
-
7. Git Tools
- 7.1 Hersieningseleksie (Revision Selection)
- 7.2 Interaktiewe Voorbereiding (Interactive Staging)
- 7.3 Bêre en Skoonmaak (Stashing and Cleaning)
- 7.4 Ondertekening van Jou Werk (Signing Your Work)
- 7.5 Soek (Searching)
- 7.6 Herskryf van Geskiedenis (Rewriting History)
- 7.7 Reset Ontmystifiseer (Reset Demystified)
- 7.8 Gevorderde Saamsmelting (Advanced Merging)
- 7.9 Rerere
- 7.10 Ontfouting met Git (Debugging with Git)
- 7.11 Submodules
- 7.12 Bundeling (Bundling)
- 7.13 Vervang (Replace)
- 7.14 Die Stoor van Aanmeldbewyse (Credential Storage)
- 7.15 Summary
-
8. Customizing Git
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
1.1 Aan die slag - Oor Weergawebeheer
Hierdie hoofstuk handel oor hoe om met Git aan die slag te gaan. Ons sal begin deur 'n bietjie agtergrondinligting oor weergawebeheerstelsels te gee, daarna oorgaan na hoe om Git op jou stelsel aan die gang te kry, en laastens hoe om dit op te stel sodat jy daarmee kan begin werk. Aan die einde van hierdie hoofstuk behoort jy te verstaan waarom Git bestaan, hoekom jy dit moet gebruik, en sal jy ten volle gereed wees om daarmee aan die slag te gaan.
Oor Weergawebeheer
Wat is “weergawebeheer”, en waarom sou jy jou daaroor bekommer? Weergawebeheer is 'n stelsel wat veranderinge aan 'n lêer of 'n groep lêers oor tyd aanteken sodat jy later spesifieke weergawes kan herroep. In die voorbeelde in hierdie boek is dit sagteware-bronkode waarvan die weergawes beheer word, maar in die praktyk kan enige tipe lêer op 'n rekenaar aan weergawebeheer onderwerp word.
As jy 'n grafiese ontwerper is of webwerwe ontwerp en elke weergawe van 'n prent of uitleg wil bewaar (wat jy byna seker sal wil doen), is dit baie verstandig om 'n weergawebeheerstelsel (Version Control System, afgekort tot VCS) te gebruik. Die gebruik hiervan stel jou in staat om vroeëre weergawes van lêers of die hele projek terug te kry, veranderinge tussen twee oomblikke in tyd te vergelyk, te sien wie laas iets aangepas het wat 'n probleem kon veroorsaak, wie 'n probleem veroorsaak het en wanneer, en nog baie meer. Die gebruik van 'n VCS beteken gewoonlik ook dat jy die situasie maklik kan terugdraai as jy 'n fout maak of lêers kwytraak. Daarbij kom nog dat dit alles baie min ekstra werk verg.
Plaaslike Weergawebeheerstelsels
Baie mense se voorkeurmetode vir weergawebeheer is om lêers na 'n ander gids te kopieer (en as hulle slim is, gee hulle daardie gids ook 'n datum in die naam). Hierdie metode word baie gebruik omdat dit so eenvoudig is, maar dit is ook ongelooflik foutgevoelig. Dit is maklik om te vergeet in watter gids jy is en in die verkeerde lêer te skryf, of onbedoeld oor lêers heen te kopieer.
Om hierdie probleem te hanteer, het programmeerders lank gelede plaaslike VCS’e ontwikkel wat 'n eenvoudige databasis gebruik om alle veranderinge aan lêers te beheer.
Een van die gewildste gereedskappe vir VCS was 'n stelsel genaamd RCS, wat vandag nog met baie rekenaars saamgelever word. RCS werk deur versamelings van patches (dit is die verskille tussen lêers) van die opvolgende lêerweergawes in 'n spesiale formaat op die hardeskyf te stoor. So kan jy 'n lêer reproduseer soos dit gelyk het op enige willekeurige oomblik in tyd deur al die patches bymekaar te tel.
Gesentraliseerde Weergawebeheerstelsels
Die volgende belangrike uitdaging waar mense mee te doen kry, is dat hulle moet saamwerk met ontwikkelaars op ander rekenaars. Om hierdie uitdaging aan te gaan, het hulle Gesentraliseerde Weergawebeheerstelsels (Centralized Version Control Systems, afgekort CVCS’e) ontwikkel. Hierdie stelsels, soos CVS, Subversion en Perforce, het een sentrale rekenaarbediener waarop al die weergawes van die lêers staan en 'n aantal werkstasies wat die lêers daarvandaan onttrek (check out). Vir baie jare was dit die standaard vir weergawebeheer.
Hierdie manier van weergawebeheer bied baie voordele, veral teenoor plaaslike VCS’e. Byvoorbeeld: almal weet, tot op sekere hoogte, wat die ander projekmedewerkers aan die doen is. Beheerders het 'n hoë mate van beheer oor wie wat kan doen, en dit is baie eenvoudiger om 'n CVCS te beheer as om te moet werk met plaaslike databasisse op elke werkstasie.
Maar helaas, hierdie metode het ook behoorlike nadele. Die duidelikste is die single point of failure: as die sentrale rekenaarbediener platval en 'n uur later weer terug aanlyn kom, kan niemand in daardie uur saamwerk of weergawes bewaar van die dinge waaraan hulle werk nie. As die hardeskyf waarop die sentrale databasis staan korrup raak en daar is geen rugsteune (backups) van nie, verloor jy werklik alles; die hele geskiedenis van die projek, op die toevallige momentopnames na wat mense op hul eie rekenaars het. Plaaslike VCS-stelsels het dieselfde probleem: as jy die hele geskiedenis van die projek op een enkele plek bewaar, loop jy ook kans om alles te verloor.
Verspreide Weergawebeheerstelsels
En hier verskyn Verspreide Weergawebeheerstelsels (Distributed Version Control Systems, DVCS’e) ten tonele. In 'n DVCS (soos Git, Mercurial, Bazaar of Darcs) laai werkstasies nie bloot die nuutste momentopnames van die lêers af nie; die hele opslagplek (die bewaarplek/repository) word gekopieer. Dus, as 'n willekeurige rekenaarbediener uitval en hierdie stelsels het via daardie rekenaarbediener saamgewerk, dan kan die bewaarplek van enige werkstasie teruggekopieer word na die rekenaarbediener om dit te herstel. Elke kloon is dus in werklikheid 'n volledige rugsteun van al die data.
Boonop kan baie van hierdie stelsels behoorlik goed omgaan met verskeie (afgeleë) bewaarplekke gelyktydig, sodat jy met verskillende groepe mense op verskillende maniere gelyk aan dieselfde projek kan werk. Hierdeur kan jy verskillende werkprosesse (workflows) soos hiërargiese modelle opsit wat nie moontlik sou gewees het met gesentraliseerde stelsels nie.
'n Kort geskiedenis van Git
Soos soveel goeie dinge in die lewe, het Git begin met 'n bietjie kreatiewe vernietiging en 'n hewige polemiek.
Die Linux-kern (kernel) is 'n oopbron-sagtewareprojek met 'n betreklik groot omvang. Vir 'n lang tyd tydens die instandhouding van die Linux-kern (1991–2002), is aanpassings aan die sagteware hoofsaaklik versprei via pleisters (patches) en gearchiveerde lêers. In 2002 het die projek begin om 'n geslote DVCS genaamd BitKeeper te gebruik.
In 2005 het die verhouding tussen die gemeenskap wat die Linux-kern ontwikkel het en die kommersiële maatskappy wat BitKeeper gemaak het, verbrokkel, en die program mag nie meer gratis gebruik word nie. Dit was die aanleiding vir die Linux-ontwikkelingsgemeenskap (en Linus Torvalds, die skepper van Linux, in die besonder) om hul eie gereedskap te ontwikkel, gebaseer op 'n aantal lesse wat geleer is toe hulle nog BitKeeper gebruik het. 'n Aantal van die doelwitte wat hulle vir die nuwe stelsel gehad het, was soos volg:
-
Snelheid
-
Eenvoudige ontwerp
-
Goeie ondersteuning vir nie-lineêre ontwikkeling (duisende parallelle vertakkings/branches)
-
Volledig gedistribueerd
-
In staat om doeltreffend om te gaan met groot projekte soos die Linux-kern (wat betref spoed sowel as opslagruimte)
Sedert sy ontstaan in 2005 het Git gegroei tot sy huidige vorm: dit is eenvoudig om te gebruik en het tog daardie oorspronklike eienskappe behou. Dit is ongelooflik vinnig, enorm doeltreffend met groot projekte en besit 'n ongeëwenaarde tak-stelsel (branch-system) vir die ondersteuning van nie-lineêre ontwikkeling (sien Git Branching).