Git op een server krijgen
Om een initiële Git server op te zetten, moet je een bestaande repository in een kale repository exporteren — een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen. Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de --bare optie. Als vaste gewoonte eindigen de namen van kale repository mappen in .git, zoals:
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/De uitvoer van dit commando is een beetje verwarrend. Omdat clone eigenlijk een git init en dan een git fetch is, zien we de uitvoer van het git init gedeelte, wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je my_project.git map moeten hebben.
Dit is ongeveer gelijk aan
$ cp -Rf my_project/.git my_project.gitEr zijn een paar kleine verschillen in het configuratie bestand; maar voor jouw doeleinde ligt dit dicht bij hetzelfde. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek alleen voor dat ding.
Het bare repository op een server zetten
Nu dat je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die git.example.com heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de /opt/git map. Je kunt je nieuwe repository instellen door je kale repository ernaartoe te kopiëren:
$ scp -r my_project.git user@git.example.com:/opt/gitOp dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de /opt/git map, jouw repository clonen door dit uit te voeren:
$ git clone user@git.example.com:/opt/git/my_project.gitAls een gebruiker in een server SSH-ed en schrijftoegang heeft tot de /opt/git/my_project.git map, dan hebben ze automatisch ook push toegang. Git zal automatisch correcte groep schrijfrechten aan een repository toevoegen als je het git init commando met de --shared optie uitvoert.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --sharedJe 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 ben je klaar om aan hetzelfde project samen te werken.
Het is belangrijk om te zien dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben — voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang tot hebben. Je bent er klaar voor — je hebt niets anders nodig.
In de volgende secties zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikersaccounts voor elke gebruiker omvatten, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privéproject, alles wat je nodig hebt een SSH server en een kale repository is.
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 lezen/schrijven voor anderen, dan kunnen toegang en permissies een beetje lastig in te stellen zijn.
SSH toegang
Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het gemakkelijkst om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige sectie). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het besturingssysteem 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 instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, 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 omslachtig kan zijn. Je wilt misschien niet adduser uitvoeren en tijdelijke wachtwoorden voor iedere gebruiker instellen.
Een tweede methode is een enkele ‘git’ gebruiker aanmaken 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 je nieuwe ‘git’ gebruiker. Vanaf dat punt 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 inlogd zal de commits die je opgeslagen hebt niet beïnvloeden.
Een andere manier waarop je het kunt doen is je SSH server laten verifiëren vanaf een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker een shell toegang heeft op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.