Git
Chapters ▾ 2nd Edition

4.2 Git op de server - Git op een server krijgen

Git op een server krijgen

We gaan nu het inrichten van een Git service op je eigen server behandelen waarin deze protocols worden gebuikt.

Noot

We zullen hier de commando’s en stappen laten zien om een eenvoudige, versimpelde installatie op een op Linux gebaseerde server op te zetten, alhoewel het ook mogelijk is deze services op een macOS of Windows server te draaien. Het daadwerkelijk opzetten van een productie server binnen jouw infrastructuur zal vrijwel zeker verschillen in de manier waarop de veiligheidsmaatregelen zijn ingericht of de gebruikte tooling van het besturingssysteem, maar hopelijk zal dit je een indruk geven van wat er allemaal bij komt kijken.

Om initieel een Git server op te zetten, moet je een bestaande repository naar een nieuwe kale repository exporteren — een repository die geen werk directory bevat. Dit is over het algemeen eenvoudig te doen. Om je repository clonen om daarmee een nieuwe kale repository te maken, draai je het clone commando met de --bare optie. De conventie is om directories waar kale repositories in staan te laten eindigen met .git, zoals hier:

$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.

Je zou nu een kopie van de Git directory gegevens in je my_project.git directory moeten hebben

Dit is grofweg gelijk aan

$ cp -Rf my_project/.git my_project.git

Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkdirectory, en maakt een directory specifiek hiervoor aan.

De kale repository op een server zetten

Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt die git.example.com heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de /srv/git directory. Aangenomen dat /srv/git bestaat op die server, kan je deze nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:

$ scp -r my_project.git user@git.example.com:/srv/git

Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de /srv/git directory, jouw repository clonen door dit uit te voeren:

$ git clone user@git.example.com:/srv/git/my_project.git

Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de /srv/git/my_project.git directory, dan hebben ze automatisch ook push toegang.

Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het git init commando met de --shared optie uitvoert. Merk op dat met het aanroepen van dit commando je geen enkele commit, refs, etc. zult verwijderen.

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu zijn jullie klaar om aan hetzelfde project samen te werken.

Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben: maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor — je hebt niets anders nodig.

In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je nodig hebt een SSH server is en een kale repository.

Kleine opstellingen

Als je met een kleine groep bent of net begint met Git in je organisatie en slechts een paar ontwikkelaars hebt, dan kunnen de dingen eenvoudig voor je zijn. Een van de meest gecompliceerde aspecten van een Git server instellen is het beheren van gebruikers. Als je sommige repositories alleen-lezen voor bepaalde gebruikers wilt hebben, en lees/schrijf voor anderen, dan kunnen toegang en permissies een beetje lastiger te regelen zijn.

SSH toegang

Als je al een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar op te zetten, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.

Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze opzetten. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.

Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet adduser uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.

Een tweede methode is een enkele git gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het ~/.ssh/authorized_keys bestand van die nieuwe gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de git gebruiker. Dit tast de commit data op geen enkele manier aan — de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.

Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die misschien al ingericht is. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.

scroll-to-top