-
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
4.8 Git on the Server - GitLab
GitLab
GitWeb is egter redelik simplisties. As jy op soek is na 'n moderne, ten volle toegeruste Git-bediener (Git server), is daar verskeie oopbron-oplossings (open source solutions) daar buite wat jy eerder kan installeer. Aangesien GitLab een van die gewildstes is, sal ons as voorbeeld dek hoe om dit te installeer en te gebruik. Dit is moeiliker as die GitWeb-opsie en sal meer instandhouding vereis, maar dit is 'n ten volle toegeruste opsie.
Installasie (Installation)
GitLab is 'n databasis-gerugsteunde webtoepassing (database-backed web application), so die installering daarvan is meer ingewikkeld as by sommige ander Git-bedieners. Gelukkig is hierdie proses goed gedokumenteer en ondersteun. GitLab beveel sterk aan om GitLab op jou bediener (server) te installeer via die amptelike Omnibus GitLab-pakket.
Die ander installasie-opsies is:
-
GitLab Helm-grafiek (GitLab Helm chart), vir gebruik met Kubernetes.
-
Gedoekeriseerde (Dockerized) GitLab-pakkette vir gebruik met Docker.
-
Vanaf die bronlêers (source files).
-
Wolkverskaffers (Cloud providers) soos AWS, Google Cloud Platform, Azure, OpenShift en Digital Ocean.
Vir meer inligting, lees die GitLab Community Edition (CE) readme.
Administrasie (Administration)
GitLab se administrasiekoppelvlak (administration interface) word oor die web verkry.
Wys eenvoudig jou blaaier (browser) na die gasheernaam (hostname) of IP-adres waar GitLab geïnstalleer is, en meld aan as die root gebruiker.
Die wagwoord sal afhang van jou installasietipe, maar by verstek (by default) genereer Omnibus GitLab outomaties 'n wagwoord daarvoor en stoor dit in /etc/gitlab/initial_root_password vir ten minste 24 uur.
Volg die dokumentasie vir meer besonderhede.
Nadat jy aangemeld het, klik op die “Admin area” ikoon in die kieslys regs bo.
Gebruikers (Users)
Almal wat jou GitLab-bediener gebruik, moet 'n gebruikersrekening (user account) hê.
Gebruikersrekeninge is redelik eenvoudig; dit bevat hoofsaaklik persoonlike inligting gekoppel aan aantekendata (login data).
Elke gebruikersrekening het 'n naampas (namespace), wat 'n logiese groepering is van projekte wat aan daardie gebruiker behoort.
As die gebruiker jane 'n projek genaamd project gehad het, sou daardie projek se URL http://server/jane/project wees.
Jy kan 'n gebruikersrekening op twee maniere verwyder:
Deur 'n gebruiker te “blokkeer” (Blocking), word verhoed dat hulle op die GitLab-instansie aanmeld, maar al die data onder daardie gebruiker se naampas sal behoue bly, en vasleggings (commits) wat met daardie gebruiker se e-posadres onderteken is, sal steeds terugskakel na hul profiel.
Aan die ander kant, deur 'n gebruiker te “vernietig” (Destroying), word hulle heeltemal van die databasis en lêerstelsel verwyder.
Alle projekte en data in hul naampas (namespace) word verwyder, en enige groepe wat hulle besit sal ook verwyder word.
Dit is natuurlik 'n baie meer permanente en vernietigende aksie, en jy sal dit selde nodig hê.
Groepe (Groups)
'n GitLab-groep is 'n versameling projekte, tesame met data oor hoe gebruikers toegang tot daardie projekte kan verkry.
Elke groep het 'n projek-naampas (die selfde manier as wat gebruikers dit het), so as die groep training 'n projek genaamd materials het, sou die URL http://server/training/materials wees.
Elke groep is geassosieer met 'n aantal gebruikers, en elkeen het 'n sekere vlak van regte (permissions) vir die groep se projekte en die groep self.
Dit wissel van “Gas” (Guest - slegs kwessies en klets) tot “Eienaar” (Owner - volle beheer oor die groep, sy lede en sy projekte).
Die tipe regte is te veel om hier te lys, maar GitLab het 'n nuttige skakel op die administrasieskerm.
Projekte (Projects)
'n GitLab-projek kom min of meer ooreen met 'n enkele Git-bewaarplek (repository). Elke projek behoort aan 'n enkele naampas (namespace), hetsy 'n gebruiker of 'n groep. As die projek aan 'n gebruiker behoort, het die eienaar van die projek direkte beheer oor wie toegang tot die projek het; as die projek aan 'n groep behoort, sal die groep se gebruikervlak-regte (user-level permissions) in werking tree.
Elke projek het 'n sigbaarheidsvlak (visibility level), wat beheer wie leestoegang (read access) tot daardie projek se bladsye en bewaarplek het.
As 'n projek Privaat (Private) is, moet die projek se eienaar eksplisiet toegang aan spesifieke gebruikers verleen.
'n Interne (Internal) projek is sigbaar vir enige aangemelde gebruiker, en 'n Publieke (Public) projek is sigbaar vir enigiemand.
Let daarop dat dit beide git fetch toegang beheer, asook toegang tot die web-UI vir daardie projek.
Hake (Hooks)
GitLab sluit ondersteuning vir hake (hooks) in, beide op 'n projek- of stelselvlak. Vir enige van hierdie sal die GitLab-bediener 'n HTTP POST uitvoer met beskrywende JSON wanneer relevante gebeure plaasvind. Dit is 'n wonderlike manier om jou Git-bewaarplekke en GitLab-instansie te koppel aan die res van jou ontwikkelingsoutomatisering, soos CI-bedieners, kletskamers (chat rooms), of uitrol-gereedskap (deployment tools).
Basiese Gebruik (Basic Usage)
Die eerste ding wat jy met GitLab sal wil doen, is om 'n nuwe projek te skep. Jy kan dit doen deur op die “+” ikoon in die nutsbalk (toolbar) te klik. Jy sal gevra word vir die projek se naam, aan watter naampas (namespace) dit behoort, en wat sy sigbaarheidsvlak (visibility level) moet wees. Die meeste van wat jy hier spesifiseer, is nie permanent nie, en kan later deur die instellingskoppelvlak (settings interface) verander word. Klik op “Create Project”, en jy is klaar.
Sodra die projek bestaan, sal jy dit waarskynlik met 'n plaaslike Git-bewaarplek (local Git repository) wil koppel.
Elke projek is toeganklik oor HTTPS of SSH, wat enigeen gebruik kan word om 'n Git-remote op te stel.
Die URL’e is sigbaar bo-aan die projek se tuisblad.
Vir 'n bestaande plaaslike bewaarplek, sal hierdie opdrag 'n afgeleë bewaarplek (remote) genaamd gitlab na die gasheerligging skep:
$ git remote add gitlab https://server/namespace/project.gitAs jy nie 'n plaaslike kopie van die bewaarplek het nie, kan jy eenvoudig dit doen:
$ git clone https://server/namespace/project.gitDie web-UI bied toegang tot verskeie nuttige aansigte (views) van die bewaarplek self. Elke projek se tuisblad wys onlangse aktiwiteit, en skakels (links) bo-aan sal jou na aansigte van die projek se lêers en vasleggingslog (commit log) lei.
Saamwerk (Working Together)
Die eenvoudigste manier om saam aan 'n GitLab-projek te werk, is deur aan elke gebruiker direkte push-toegang tot die Git-bewaarplek te gee.
Jy kan 'n gebruiker by 'n projek voeg deur na die “Lede” (Members) afdeling van daardie projek se instellings te gaan, en die nuwe gebruiker aan 'n toegangsvlak (access level) te koppel (die verskillende toegangsvlakke word in 'n mate bespreek in Groepe (Groups)).
Deur vir 'n gebruiker 'n toegangsvlak van “Ontwikkelaar” (Developer) of hoër te gee, kan daardie gebruiker vasleggings (commits) en takke (branches) direk na die bewaarplek push.
'n Ander, meer ontkoppelde (decoupled) manier van samewerking is deur gebruik te maak van saamsmeltingsversoeke (merge requests).
Hierdie kenmerk stel enige gebruiker in staat wat 'n projek kan sien, om op 'n beheerde manier daartoe by te dra.
Gebruikers met direkte toegang kan bloot 'n tak (branch) skep, vasleggings (commits) soontoe push, en 'n saamsmeltingsversoek van hul tak af terug in master of enige ander tak oopmaak.
Gebruikers wat nie push-regte (push permissions) vir 'n bewaarplek het nie, kan dit “vurk” (fork) om hul eie kopie te skep, vasleggings na hul kopie push, en 'n saamsmeltingsversoek vanaf hul gevurkte weergawe na die hoofprojek oopmaak.
Hierdie model stel die eienaar in staat om ten volle in beheer te wees van wat in die bewaarplek ingaan en wanneer, terwyl dit bydraes van onbekende (untrusted) gebruikers toelaat.
Saamsmeltingsversoeke (merge requests) en kwessies (issues) is die hoofeenhede van langdurige besprekings in GitLab. Elke saamsmeltingsversoek laat 'n reël-vir-reël bespreking van die voorgestelde verandering toe (wat 'n liggewig tipe kodehersiening / code review ondersteun), sowel as 'n algemene oorhoofse besprekingsdraad (discussion thread). Beide kan aan gebruikers toegewys word, of in mylpale (milestones) georganiseer word.
Hierdie afdeling is hoofsaaklik gefokus op die Git-verwante kenmerke van GitLab, maar as 'n volwasse projek bied dit baie ander funksies om jou span te help saamwerk, soos projek-wiki’s en stelselinstandhoudingsinstrumente (system maintenance tools). Een voordeel van GitLab is dat, sodra die bediener opgestel is en loop, jy selde nodig sal hê om aan 'n konfigurasielêer te verander of via SSH toegang tot die bediener te verkry; die meeste administrasie en algemene gebruik kan deur die blaaier-koppelvlak (in-browser interface) gedoen word.