-
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.6 Git op de server - Slimme HTTP
Slimme HTTP
We hebben nu geauthenticeerde toegang via SSH en ongeauthenticeerde toegang met git://
, maar er is een protocol die tot beide in staat is.
Slimme HTTP opzetten is eigenlijk gewoon op de server een CGI script git-http-backend
geheten activeren die met Git wordt geleverd.
Deze CGI leest het pad en de headers die door een git fetch
of een git push
worden gestuurd aan een HTTP URL en bepaalt of de client via HTTP kan communiceren (wat elke client sinds versie 1.6.6 kan).
Als de CGI ziet dat de client "slim" is, zal het op de slimme manier met deze communiceren, anders zal het terugvallen op het domme gedrag (dus het is "backward compatible" met lees acties van oudere clients).
Laten we een heel eenvoudige opzet doornemen. We zullen het gaan opzetten met Apache als de CGI server. Als je geen Apache hebt geïnstalleerd, kan je dit op een Linux machine doen met iets wat lijkt op:
$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias env
Dit zet mod_cgi
, mod_alias
en mod_env
modules aan, die alle nodig zijn om dit goed te laten werken.
Je zult ook nog de Unix user groep van de /srv/git
directories naar www-data
te zetten zodat je webserver lees- en schrijfrechten heeft op de repositories, omdat de Apache instantie die de CGI script draait (standaard) draait onder die user:
$ chgrp -R www-data /srv/git
Vervolgens moeten we een aantal dingen aan de Apache configuratie toevoegen om git-http-backend
als afhandelaar te identificeren voor alles wat in het /git
pad van je web server binnenkomt.
SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Als je de GIT_HTTP_EXPORT_ALL
uit je omgevingsvariabele laat, zal Git alleen de repositories met het git-daemon-export-ok
bestand erin verspreiden, net zoals de Git daemon deed.
Als laatste moet je Apache vertellen om verzoeken naar paden toe te staan die er zo uit zien, optioneel met een Auth block zoals hier:
<Files "git-http-backend">
AuthType Basic
AuthName "Git Access"
AuthUserFile /srv/git/.htpasswd
Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
Require valid-user
</Files>
Dat verplicht je een .htaccess
bestand aan te maken met daarin de wachtwoorden van al de geldige gebruikers.
Hier is een voorbeeld van hoe een “schacon” gebruiker toe te voegen aan het bestand:
$ htpasswd -c /srv/git/.htpasswd schacon
Er zijn tig manieren om geauthenticeerde gebruikers in Apache aan te geven, je zult een keuze moeten maken en een van deze implementeren. Dit is gewoon een van de eenvoudigste voorbeelden die we konden verzinnen. Je zult dit waarschijnlijk ook over SSL willen opzetten, zodat alle gegevens zijn versleuteld.
We willen ons niet te veel bochten wringen om de specifieke zaken van Apache configuraties uit de doeken te doen, je gebruikt misschien een andere server of andere authenticatie behoeften hebben.
De clou is dat Git met een CGI geleverd wordt die git-http-backend
heet die, wanneer geactiveerd, alle onderhandelingen doet teneinde bestanden te sturen en te ontvangen over HTTP.
Deze implementeert het authenticeren zelf niet, maar dat kan eenvoudig worden beheerd op het niveau van de server die dit aanroept.
Je kunt dit met vrijwel elke web server met CGI capaciteiten, dus pas het vooral toe op hetgeen waar je het meest bekend mee bent.
Noot
|
Voor meer informatie over het configureren van authenticatie in Apache, verwijzen we je naar de volgende Apache documentatie: https://httpd.apache.org/docs/current/howto/auth.html |