Als u bronbeheer voor een project wilt instellen, maar liever niet om het op een service als GitHub te hosten, kun je je eigen git-server op een VPS draaien om je code op te slaan en als hoofdopslagplaats voor eventuele bijdragers te fungeren.
Waarom je eigen server draaien?
Met hoeveel gratis gehoste git-providers er zijn, zoals GitHub, GitLab en Bitbucket, heeft het weinig zin om het zelf te doen. Maar er zijn een paar situaties waarin het een haalbare oplossing is.
Ten eerste is het runnen van je eigen server veel meer privé, vooral als je werkt aan code die je liever niet opslaat in de cloud van iemand anders. Dit wil niet zeggen dat providers zoals GitLab niet veilig zijn, maar alles zelf hosten kan sommige mensen meer gemoedsrust geven.
Ook als je een derde- partyservice, zijn er beperkingen aan de bestandsgrootte die misschien niet ideaal zijn. GitHub staat geen bestanden van meer dan 100 MB toe, wat een groot probleem kan zijn voor projecten met grote binaire bestanden. Als u uw eigen server gebruikt, wordt deze limiet opgeheven, ervan uitgaande dat u kunt betalen voor meer ruimte op de harde schijf.
Wat je use-case ook is, je kunt het waarschijnlijk beter doen dan barebones git. GitLab's Community Edition is gratis en open source, en is eenvoudig in te stellen op uw eigen server. Dit geeft je alle voordelen van het zelf hosten, samen met een zeer mooie webinterface en talloze CI/CD-tools. We raden je ten zeerste aan om GitLab te gebruiken als je vrije serverruimte hebt. (Er is ongeveer 3 GB RAM voor nodig.) Lees onze handleiding voor het installeren en configureren voor meer informatie.
Advertentie
Maar als je niet alle toeters en bellen wilt en gewoon een eenvoudige git-afstandsbediening wilt gebruiken, kun je verder lezen.
Git Remotes zijn gewoon de opslagplaats van iemand anders
Het eerste dat opvalt over git is dat het hosten van een server eigenlijk niet erg ingewikkeld is. Git gebruikt een gedistribueerd bronbeheermodel; uw lokale kloon van een repository maakt helemaal geen verbinding met al uw collega's, maar maakt wel verbinding met een “remote,” meestal op een externe centrale server of dienst. Als je duwt en trekt, breng je wijzigingen aan in de officiële masterkopie van de afstandsbediening. Wanneer uw collega's van de afstandsbediening ophalen, downloaden ze uw commits.
Technisch gezien kun je git uitvoeren als een volledig gedecentraliseerde service. Als je twee mensen had, zouden ze elk updates van elkaar ophalen. (Pushen naar niet-server repositories wordt in deze opzet niet aangeraden.) Dit is in de praktijk niet echt bruikbaar, tenzij beide partijen statische IP-adressen hebben en altijd online zijn, dus de meeste mensen kiezen voor de server-client model.
Dus alles wat een git-server is, is gewoon een gewone repository die is geconfigureerd als de hoofdkopie en open staat voor internet. Het is verrassend eenvoudig in te stellen. Eerst moeten we een nieuwe gebruiker aanmaken. Git gebruikt SSH voor authenticatie en al het verkeer tussen servers en clients, dus we hebben een servicegebruiker nodig om de repo te beheren.
sudo useradd git
Schakel vervolgens over naar de git-gebruiker voor de rest van de installatie:
su git
Je moet je SSH-sleutels toevoegen aan het git-gebruiker's Authorized_keys-bestand:
nano ~/.ssh/authorized_keys Advertentie
Dit is een gebied waar services zoals GitHub en GitLab de opdrachtregel Git beat hebben. Toegangsbeheer is niet eenvoudig op deze manier te regelen, omdat u iedereen toegang moet geven tot dezelfde servicegebruiker, wat niet ideaal is, of u moet afzonderlijke gebruikers instellen voor elke persoon, wat ook niet ideaal is. Hoe dan ook, commits zullen verschijnen met de gebruikersnaam en het e-mailadres dat de eindgebruiker heeft geconfigureerd in zijn git-instellingen.
Hoe dan ook, om de daadwerkelijke repository te maken, voer je gewoon git init in het huis van de git-gebruiker uit directory:
git init –bare repository.git
De –bare optie is hier noodzakelijk. Gewoonlijk, wanneer je een repository kloont, slaat git alle bestanden die het gebruikt om versies te beheren op in de verborgen .git-map, en het houdt een bruikbare versie bij van waar je momenteel uitgecheckte HEAD zich bevindt. Dit maakt je repo-map meestal ongeveer twee keer zo groot als het zou zijn zonder git, hoewel het groter kan zijn als je grote binaire bestanden hebt en in de loop van de tijd veel verandert.
Een kale repository is gewoon een repo zonder de bruikbare versies van de momenteel uitgecheckte bestanden. In plaats daarvan is de repository-map slechts de inhoud van wat de .git-map zou zijn. Dit bespaart opslagruimte en configureert de repository als een masterserver. Omdat er geen lokale inhoud is, zullen er geen conflicten zijn met de branch HEAD. Het is gebruikelijk om kale repositories een naam te geven met de .git-bestandsextensie, maar het is niet expliciet vereist.
Dat is alles wat nodig is aan de serverzijde. Vanaf je lokale computer moet je de repo klonen of een nieuwe remote toevoegen:
git remote add origin git@example.com:repository.git
De URL begint met git@ omdat het 8217 maakt verbinding via SSH als de git-gebruiker. De :repository.git aan het einde is eigenlijk een padnaam, niet alleen een ID. Het pad is relatief aan de homedirectory van de git-gebruiker, dus als je de repo ergens anders hebt geplaatst, moet je het hierheen verplaatsen of de volledige padnaam gebruiken.
Advertentie
Nadat u uw lokale opslagplaats hebt verbonden, zou u volledige toegang moeten hebben om zoals normaal te pushen en te trekken. Houd er echter rekening mee dat standaard git geen ingebouwd machtigingssysteem heeft, dus er is niets dat iemand met toegang tot de git-gebruiker ervan weerhoudt volledige controle te hebben over je hoofdrepository.