-
1. Aan de slag
- 1.1 Over versiebeheer
- 1.2 Een kort historisch overzicht van Git
- 1.3 Wat is Git?
- 1.4 De commando-regel
- 1.5 Git installeren
- 1.6 Git klaarmaken voor eerste gebruik
- 1.7 Hulp krijgen
- 1.8 Samenvatting
-
2. Git Basics
-
3. Branchen in Git
- 3.1 Branches in vogelvlucht
- 3.2 Eenvoudig branchen en mergen
- 3.3 Branch-beheer
- 3.4 Branch workflows
- 3.5 Branches op afstand (Remote branches)
- 3.6 Rebasen
- 3.7 Samenvatting
-
4. Git op de server
- 4.1 De protocollen
- 4.2 Git op een server krijgen
- 4.3 Je publieke SSH sleutel genereren
- 4.4 De server opzetten
- 4.5 Git Daemon
- 4.6 Slimme HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Hosting oplossingen van derden
- 4.10 Samenvatting
-
5. Gedistribueerd Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisie Selectie
- 7.2 Interactief stagen
- 7.3 Stashen en opschonen
- 7.4 Je werk tekenen
- 7.5 Zoeken
- 7.6 Geschiedenis herschrijven
- 7.7 Reset ontrafeld
- 7.8 Mergen voor gevorderden
- 7.9 Rerere
- 7.10 Debuggen met Git
- 7.11 Submodules
- 7.12 Bundelen
- 7.13 Vervangen
- 7.14 Het opslaan van inloggegevens
- 7.15 Samenvatting
-
8. Git aanpassen
- 8.1 Git configuratie
- 8.2 Git attributen
- 8.3 Git Hooks
- 8.4 Een voorbeeld van Git-afgedwongen beleid
- 8.5 Samenvatting
-
9. Git en andere systemen
- 9.1 Git als een client
- 9.2 Migreren naar Git
- 9.3 Samenvatting
-
10. Git Binnenwerk
- 10.1 Binnenwerk en koetswerk (plumbing and porcelain)
- 10.2 Git objecten
- 10.3 Git Referenties
- 10.4 Packfiles
- 10.5 De Refspec
- 10.6 Uitwisseling protocollen
- 10.7 Onderhoud en gegevensherstel
- 10.8 Omgevingsvariabelen
- 10.9 Samenvatting
-
A1. Bijlage A: Git in andere omgevingen
- A1.1 Grafische interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Samenvatting
-
A2. Bijlage B: Git in je applicaties inbouwen
- A2.1 Commando-regel Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bijlage C: Git Commando’s
- A3.1 Setup en configuratie
- A3.2 Projecten ophalen en maken
- A3.3 Basic Snapshotten
- A3.4 Branchen en mergen
- A3.5 Projecten delen en bijwerken
- A3.6 Inspectie en vergelijking
- A3.7 Debuggen
- A3.8 Patchen
- A3.9 Email
- A3.10 Externe systemen
- A3.11 Beheer
- A3.12 Binnenwerk commando’s (plumbing commando’s)
4.8 Git op de server - GitLab
GitLab
GitWeb is echter nogal simplistisch. Als je op zoek bent naar een meer moderne Git server met alle toeters en bellen, zijn er een aantal open source oplossingen die je als alternatief kunt installeren. Omdat GitLab een van de meer populaire alternatieven is, zullen we het installeren en gebruiken als voorbeeld bespreken. Dit is iets complexer dan de GitWeb optie en vergt waarschijnlijk meer onderhoud, maar het is een optie met veel meer mogelijkheden.
Installatie
GitLab is een applicatie die door een database wordt ondersteund, de installatie houdt daarom iets meer in dan andere Git servers. Gelukkig is dit proces zeer goed gedocumenteerd en ondersteund.
Er zijn een aantal methoden die je kunt volgen om GitLab te installeren. Om iets snel in de lucht te krijgen, kan je een image van een virtuele machine downloaden of een klik op de knop installatie programma van https://bitnami.com/stack/gitlab, en de configuratie wat bijstellen voor jouw specifieke omgeving. Bitnami heeft een prettig detail toegevoegd endat is het login scherm (bereikbaar door alt-→ te typen); het geeft je het IP adres en standaard gebruikersnaam en wachtwoord voor de geïnstalleerde GitLab.
Voor de rest, volg de handleiding in het GitLab Community Edition readme-bestand, welke gevonden kan worden op https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Daar vind je ondersteuning voor het installeren van GitLab gebruikmakend van Chef-recepten, een virtual machine op Digital Ocean en RPM en DEB-pakketten (die, ten tijde van schrijven, in beta zijn). Er is ook een “onofficieel” handleiding over hoe GitLab op een niet standaard besturingssysteem en database aan de praat te krijgen, een installatie-script voor het volledig handmatig installeren, en vele andere onderwerpen.
Beheer
De beheer interface van GitLab is via het web benaderbaar.
Simpelweg de hostnaam of IP adres waar GitLab is geïnstalleerd in je browser invullen, en inloggen als beheer-gebruiker.
De standaard gebruikersnaam is admin@local.host, en het standaard wachtwoord is 5iveL!fie (en je wordt er aan herinnerd om dit te wijzigen zodra je het intypt).
Zodra je aangemeld bent, klik op het “Admin area” icoon in het menu rechts boven.
Gebruikers
Gebruikers in GitLab zijn accounts die overeenkomen met personen.
Gebruiker accounts hebben niet veel complexiteit; het is voornamelijk een verzameling van persoonlijke gegevens die bij login-gegevens horen.
Elke gebruiker heeft een namespace, wat een logische groepering van projecten is die bij die gebruiker horen.
Als de gebruiker jane een project genaamd project zou hebben, zou de URL van dat project http://server/jane/project zijn.
Een gebruiker kan op twee manieren worden verwijderd. Een gebruiker “Blocken” (blokkeren) verhindert ze om in te loggen in deze GitLab instantie, maar alle gegevens onder de namespace van die gebruiker blijven intact, en commits met het email adres van die gebruiker zullen nog steeds naar die profiel terugverwijzen.
Een gebruiker “Destroyen” (vernietigen) echter verwijdert deze volledig van de database en het bestandssysteem. Alle projecten en gegevens in de namespace worden verwijderd, en alle groepen die met die gebruiker als eigenaar worden ook verwijderd. Dit is duidelijk een aktie met meer permanente en vernietigende gevolgen, en het wordt ook zelden gebruikt.
Groepen
Een GitLag groep is een verzameling van projecten, samen met gegevens hoe gebruikers deze projecten kunnen benaderen.
Elke groep heeft een project namespace (op gelijke manier waarop gebruikers dit hebben), dus als de groep training een project genaamd materials heeft, zou de url http://server/training/materials zijn.
Elke groep heeft een relatie met een aantal gebruikers, elk van hen heeft een mate van permissies op de projecten van de groep en de groep zelf. Deze varieren van “Guest” (gast) (alleen problemen en chat) tot “Owner” (eigenaar) (volledig beheer over de groep, haar leden en projecten). De lijst van permissies is te groot om hier weer te geven, maar GitLab heeft een behulpzame link op het beheerscherm.
Projecten
Een GitLab project komt grofweg overeen met een enkele Git repository. Elk project behoort tot één enkele namespace, ofwel een gebruiker of een groep. Als het project bij een gebruiker hoort, heeft de eigenaar van het project direct controle over wie toegang heeft tot het project; als het project tot een groep behoort, beginnen de permissies van de gebruikers binnen die groep ook een rol te spelen.
Elk project heeft een niveau van zichtbaarheid, welke bepaalt wie lees rechten tot de pagina’s van het project en de repository heeft.
Als een project Private is, moet de eigenaar van dat project expliciet toegang verlenen aan specifieke gebruikers.
Als een project Internal (intern) is, is deze zichtbaar voor elke aangemelde gebruiker, en een Public project is zichtbaar voor iedereen.
Let wel dat dit zowel de git fetch toegang als de toegang middels de web gebruikers interface voor dat project regelt.
Hooks (haken)
GitLab ondersteunt het gebruik van hooks, zowel op een project als systeem niveau. Voor beiden zal de GitLab server een HTTP POST uitvoeren met wat beschrijvende JSON elke keer als er relevante gebeurtenissen plaatvinden. Dit is een goede manier om je Git repositories en de GitLab instantie te verbinden met de rest van je ontwikkel-automatisering, zoals CI servers, chat rooms of deployment tools.
Eenvoudig gebruik
Het eerste wat je binnen GitLab zult willen doen is het maken van een nieuw project. Dit wordt gedaan door het “+” icoon te klikken in de toolbar. Er zal worden gevraagd naar de naam van het project, welke namespace het toe behoort en wat het niveau van zichtbaarheid het moet hebben. Het meeste wat je hier aangeeft is niet permanent, het kan later veranderd worden middels het settings (instellingen) interface. Klik op ``Create Project"`, en je bent klaar.
Als het project eenmaal bestaat, zal je het waarschijnlijk met een lokale Git repository willen verbinden.
Elk project is toegangkelijk via HTTPS of SSH, beide kunenn worden gebruikt om ee Git remote op te zetten.
De URLs zijn te zien aan de bovenkant van de thuis-pagina van het project.
Voor een bestaande lokale repository zal dit commando een remote genaamd gitlab aanmaken naar de gehoste locatie:
$ git remote add gitlab https://server/namespace/project.gitAls je geen lokale kopie hebt van de repository, kan je simpelweg dit doen:
$ git clone https://server/namespace/project.gitDe web gebruikersinterface geeft toegang tot een aantal nuttige kijken op de repository. Elke thuis-pagina van een project laat de recente activiteit zien, en links aan de bovenkant zullen je naar overzichten voeren van de bestanden van het project en de commit log.
Samenwerken
De eenvoudigste manier van samenwerken op een GitLab project is door een andere gebruiker direct push-toegang te geven tot de Git repository. Je kunt een gebruiker aan een project toevoegen door naar het “Members” (leden) gedeelte te gaan van de instellingen van dat project, en de nieuwe gebruiker een toegangsniveau toe te wijzen (de verschillende niveaus worden een beetje besproken in Groepen). Door een gebruiker een toegangsniveau van “Developer” of hoger te geven, kan die gebruiker commits pushen en straffeloos branches direct aan de repository toevoegen.
Een andere, meer ontkoppelde manier van samenwerken is door gebruik te maken van merge-requests (verzoeken tot samenvoeging).
Deze mogelijkheid maakt het mogelijk dat elke gebruiker die het project kan zien eraan kan bijdragen op een meer beheerde manier.
Gebruikers met directe toegang kunnen simpelweg een branch maken, hier commits naar pushen en een merge request openen om vanuit hun branch naar master of elke ander branch te mergen.
Gebruikers die geen push-toestemming hebben voor een repository kunnen deze “forken” (hun eigen kopie maken), commits naar die kopie pushen, en een merge request openen vanuit hun fork terug naar het hoofdproject.
Dit model stelt de eigenaar in staat om alles wat en wanneer er in de repository gebeurt volledig te beheersen, en tegelijkertijd bijdragen van niet vertrouwde gebruikers toe te staan.
Merge requests en issues (problemen) zijn de hoofdbestanddelen van langlopende discussies in GitLab. Elke merge request staat een regel-voor-regel discussie toe van de voorgestelde wijziging (wat de mogelijkheid opent voor een lichtgewicht code-review), alsook een generieke discussie thread. Beide kunnen aan gebruikers worden toegewezen of gegroepeerd in mijlpalen.
Deze paragraaf is voornamelijk gericht op Git-gerelateerde mogelijkheden van GitLab; maar als een volwassen project biedt het vele andere mogelijkheden om je team samen te laten werken, zoals project wiki’s en systeem onderhoudsinstrumenten. Een voordeel van GitLab is dat, zodra de server is ingericht en loopt, je nauwelijks nog aanpassingen aan de configuratie bestand hoeft te doen of de server via SSH moet benaderen. De meeste beheer en generieke gebruikshandelingen kunnen via de browser interface plaatsvinden.
