Wenn Sie die Quellcodeverwaltung für ein Projekt einrichten möchten, es aber nicht vorziehen Um es auf einem Dienst wie GitHub zu hosten, können Sie Ihren eigenen Git-Server auf einem VPS ausführen, um Ihren Code zu speichern und als Master-Repository für alle Mitarbeiter zu fungieren.
Warum einen eigenen Server betreiben?
Bei so vielen kostenlosen gehosteten Git-Providern wie GitHub, GitLab und Bitbucket macht es nicht viel Sinn, dies selbst zu tun. Es gibt jedoch einige Situationen, in denen dies eine praktikable Lösung ist.
Zunächst einmal ist der Betrieb eines eigenen Servers viel privater, insbesondere wenn Sie an Code arbeiten, den Sie lieber nicht in der “Cloud eines anderen speichern möchten.” Das soll nicht heißen, dass Anbieter wie GitLab nicht sicher sind, aber alles selbst zu hosten kann einigen Leuten mehr Sicherheit geben.
Auch wenn Sie einen Drittanbieter verwenden. Party-Service, gibt es Einschränkungen bezüglich der Dateigröße, die möglicherweise nicht ideal sind. GitHub lässt keine Dateien über 100 MB zu, was bei Projekten mit großen Binärdateien ein großes Problem darstellen kann. Wenn Sie Ihren eigenen Server verwenden, wird dieses Limit aufgehoben, vorausgesetzt, Sie können für mehr Festplattenspeicher bezahlen.
Was auch immer Ihr Anwendungsfall ist, Sie können es wahrscheinlich besser als Barebones-Git. Die Community Edition von GitLab ist kostenlos und Open Source und lässt sich einfach auf Ihrem eigenen Server einrichten. Dies bietet Ihnen alle Vorteile des eigenen Hostens zusammen mit einer sehr schönen Weboberfläche und zahlreichen CI/CD-Tools. Wir empfehlen Ihnen dringend, GitLab zu verwenden, wenn Sie freien Serverspeicherplatz haben. (Es erfordert ungefähr 3 GB RAM.) Sie können unseren Leitfaden zur Installation und Konfiguration lesen, um mehr zu erfahren.
Werbung
Wenn Sie jedoch nicht den ganzen Schnickschnack wollen und nur eine einfache Git-Fernbedienung ausführen möchten, können Sie weiterlesen.
Git-Fernbedienungen sind nur das Repository von jemand anderem
Das erste, was bei Git zu beachten ist, ist, dass das Hosten eines Servers eigentlich nicht sehr kompliziert ist. Git verwendet ein verteiltes Versionsverwaltungsmodell; Ihr lokaler Klon eines Repositorys verbindet sich nicht mit allen Ihren Kollegen, aber er verbindet sich mit einer “Remote” normalerweise auf einem externen zentralen Server oder Dienst. Wenn Sie drücken und ziehen, nehmen Sie Änderungen an der offiziellen Masterkopie der Fernbedienung vor. Wenn Ihre Kollegen von der Fernbedienung abrufen, laden sie Ihre Commits herunter.
Sie können git technisch als vollständig dezentralisierten Dienst ausführen. Wenn Sie zwei Personen hätten, würden sie jeweils Updates voneinander abrufen. (Das Pushen auf Nicht-Server-Repositorys wird in diesem Setup nicht empfohlen.) Dies ist in der Praxis nicht wirklich brauchbar, es sei denn, beide Parteien haben statische IP-Adressen und sind immer online, daher entscheiden sich die meisten Leute für den Server-Client model.
Ein Git-Server ist also nur ein normales Repository, das als Masterkopie konfiguriert und für das Internet geöffnet ist. Es ist überraschend einfach einzurichten. Zuerst müssen wir einen neuen Benutzer erstellen. Git verwendet SSH für die Authentifizierung und den gesamten Datenverkehr zwischen Servern und Clients, daher benötigen wir einen Service-Benutzer, um das Repository zu verwalten.
sudo useradd git
Wechseln Sie als Nächstes für den Rest der Einrichtung zum Git-Nutzer:
su git
Sie müssen Ihre SSH-Schlüssel zur Datei “authorized_keys” des Git-Nutzers hinzufügen:
nano ~/.ssh/authorized_keys Werbung
Dies ist ein Bereich, in dem Dienste wie GitHub und GitLab die Befehlszeile von Git schlagen. Die Zugriffsverwaltung ist auf diese Weise nicht einfach zu handhaben, da Sie jedem Zugriff auf denselben Dienstbenutzer gewähren müssen, was nicht ideal ist, oder Sie müssen separate Benutzer für einrichten jede Person, was auch nicht ideal ist. In jedem Fall werden Commits mit dem Benutzernamen und der E-Mail angezeigt, die der Endbenutzer in seinen git-Einstellungen konfiguriert hat.
Wie auch immer, um das eigentliche Repository zu erstellen, führen Sie einfach git init in der Startseite des git-Benutzers aus Verzeichnis:
git init –bare repository.git
Die Option –bare ist hier erforderlich. Wenn Sie ein Repository klonen, speichert git normalerweise alle Dateien, die es zum Verwalten von Versionen verwendet, im versteckten .git-Ordner und behält eine verwendbare Version von dem, wo sich Ihr aktuell ausgecheckter HEAD befindet. Dadurch wird Ihr Repo-Ordner normalerweise etwa doppelt so groß wie ohne Git, obwohl er größer sein kann, wenn Sie große Binärdateien haben und im Laufe der Zeit viele Änderungen vornehmen.
Ein Bare-Repository ist einfach ein Repository ohne die verwendbaren Versionen der aktuell ausgecheckten Dateien. Stattdessen ist der Repository-Ordner nur der Inhalt des .git-Ordners. Dies spart Speicherplatz und konfiguriert das Repository als Master-Server. Da kein lokaler Inhalt vorhanden ist, gibt es keine Konflikte mit dem Zweig HEAD. Es ist üblich, Bare-Repositorys mit der Dateierweiterung .git zu benennen, dies ist jedoch nicht explizit erforderlich.
Das ist alles, was serverseitig erforderlich ist. Von Ihrem lokalen Computer aus müssen Sie das Repository klonen oder eine neue Fernbedienung hinzufügen:
git remote add origin git@example.com:repository.git
Die URL beginnt mit git@ weil sie ’ 8217;s stellt als Git-Benutzer eine Verbindung über SSH her. Die :repository.git am Ende ist eigentlich ein Pfadname, nicht nur eine Kennung. Der Pfad ist relativ zum Home-Verzeichnis des Git-Nutzers. Wenn Sie das Repository also woanders abgelegt haben, sollten Sie es hierher verschieben oder den vollständigen Pfadnamen verwenden.
Werbung
Nachdem Sie Ihr lokales Repository verbunden haben, sollten Sie wie gewohnt vollen Zugriff auf Push und Pull haben. Beachten Sie jedoch, dass standardmäßiges Git kein integriertes Berechtigungssystem hat, sodass niemand mit Zugriff auf den Git-Nutzer die volle Kontrolle über Ihr Master-Repository hat.