it-swarm.com.de

Wie erstelle ich ein entferntes Git-Repository von einem lokalen?

Ich habe ein lokales Git-Repository. Ich möchte es auf einem entfernten, ssh-fähigen Server verfügbar machen. Wie mache ich das?

212
Nips

Ich denke, Sie machen ein nacktes Repository auf der Remote-Seite, git init --bare, füge die Remote-Seite als Push/Pull-Tracker für dein lokales Repository hinzu (git remote add Origin URL), und dann sagst du vor Ort einfach git Push Origin master. Jetzt kann jedes andere Repository pull aus dem Remote-Repository.

258
Kerrek SB

Um einen Git-Server zum ersten Mal einzurichten, müssen Sie ein vorhandenes Repository in ein neues Bare-Repository exportieren - ein Repository, das kein Arbeitsverzeichnis enthält. Dies ist im Allgemeinen einfach zu tun. Um Ihr Repository zu klonen und ein neues nacktes Repository zu erstellen, führen Sie den Befehl clone mit der Option --bare aus. Bare-Repository-Verzeichnisse enden normalerweise wie folgt auf .git:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/

Mit diesem Befehl wird das Git-Repository für sich genommen, ohne ein Arbeitsverzeichnis, und ein spezielles Verzeichnis dafür erstellt.

Nachdem Sie eine leere Kopie Ihres Repositorys haben, müssen Sie es nur noch auf einem Server ablegen und Ihre Protokolle einrichten. Angenommen, Sie haben einen Server mit dem Namen git.example.com eingerichtet, auf den Sie über SSH-Zugriff verfügen, und Sie möchten alle Ihre Git-Repositorys im Verzeichnis /opt/git speichern. Sie können Ihr neues Repository einrichten, indem Sie Ihr nacktes Repository kopieren über:

$ scp -r my_project.git [email protected]:/opt/git

Zu diesem Zeitpunkt können andere Benutzer, die über SSH-Zugriff auf denselben Server verfügen, der Lesezugriff auf das Verzeichnis /opt/git hat, Ihr Repository durch Ausführen klonen

$ git clone [email protected]:/opt/git/my_project.git

Wenn ein Benutzer sich in einen Server einloggt und Schreibzugriff auf das Verzeichnis /opt/git/my_project.git hat, hat er automatisch Push-Zugriff. Git fügt einem Repository automatisch Gruppenschreibberechtigungen hinzu, wenn Sie den Befehl git init mit der Option --shared ausführen.

$ ssh [email protected]
$ cd /opt/git/my_project.git
$ git init --bare --shared

Es ist sehr einfach, ein Git-Repository zu erstellen, eine bloße Version zu erstellen und auf einem Server abzulegen, auf den Sie und Ihre Mitarbeiter über SSH-Zugriff verfügen. Jetzt können Sie an demselben Projekt zusammenarbeiten.

71
Binoy Babu

Ein Hinweis für Leute, die die lokale Kopie unter Windows erstellt haben und ein entsprechendes Remote-Repository auf einem Unix-Line-System erstellen möchten, in dem Textdateien von Entwicklern auf Unix-like LF Endungen auf weiteren Klonen erhalten Systeme, aber CRLF-Endungen unter Windows.

Wenn Sie Ihr Windows-Repository vor Einrichten der Zeilenende-Übersetzung erstellt haben, liegt ein Problem vor. Die Standardeinstellung von Git ist keine Übersetzung, daher verwendet Ihr Arbeitssatz CRLF, aber Ihr Repository (d. H. Die unter .git gespeicherten Daten) hat die Dateien auch als CRLF gespeichert.

Wenn Sie Push an die Fernbedienung senden, werden die gespeicherten Dateien unverändert kopiert, und es wird keine Zeilenende-Übersetzung durchgeführt. (Die Übersetzung am Zeilenende erfolgt, wenn Dateien in ein Repository übertragen werden, nicht, wenn Repositorys übertragen werden.) Sie landen mit CRLF in Ihrem Unix-ähnlichen Repository, was nicht das ist, was Sie wollen.

Um LF im Remote-Repository zu erhalten, müssen Sie sicherstellen, dass sich LF zuerst im lokalen Repository befindet, indem Sie Ihr Windows-Repository neu normalisieren) . Dies hat keine sichtbaren Auswirkungen auf Ihren Windows-Arbeitssatz, der immer noch CRLF-Endungen hat. Wenn Sie jedoch auf Remote pushen, erhält die Fernbedienung LF richtig.

Ich bin mir nicht sicher, ob es eine einfache Möglichkeit gibt, festzustellen, welche Zeilenenden in Ihrem Windows - Repository vorhanden sind - Sie könnten es vermutlich testen, indem Sie core.autocrlf = false setzen und dann klonen (Wenn das Repository LF Endungen, der Klon hat LF auch).

8
user1804620

Ein Remote-Repository ist im Allgemeinen ein Bare-Repository - ein Git-Repository ohne Arbeitsverzeichnis. Da das Repository nur als Kollaborationspunkt verwendet wird, gibt es keinen Grund, einen Snapshot auf der Festplatte auschecken zu lassen. Es sind nur die Git-Daten. Im einfachsten Fall ist ein Bare-Repository der Inhalt des .git-Verzeichnisses Ihres Projekts und nichts anderes.

Sie können ein Bare-Git-Repository mit dem folgenden Code erstellen:

$ git clone --bare /path/to/project project.git

Eine Option für ein Remote-Git-Repository ist die Verwendung des SSH-Protokolls:

Ein allgemeines Transportprotokoll für Git, wenn Self-Hosting über SSH erfolgt. Dies liegt daran, dass der SSH-Zugriff auf Server an den meisten Orten bereits eingerichtet ist. Ist dies nicht der Fall, ist dies einfach. SSH ist auch ein authentifiziertes Netzwerkprotokoll. Da es allgegenwärtig ist, ist es im Allgemeinen einfach einzurichten und zu verwenden.

Um ein Git-Repository über SSH zu klonen, können Sie ein ssh:// URL wie folgt:

$ git clone ssh://[[email protected]]server/project.git

Oder Sie können die kürzere SCP-ähnliche Syntax für das SSH-Protokoll verwenden:

$ git clone [[email protected]]server:project.git

Wenn Sie oben in beiden Fällen keinen optionalen Benutzernamen angeben, geht Git davon aus, dass der Benutzer, unter dem Sie derzeit angemeldet sind.

Die Profis

Die Vorteile von SSH sind vielfältig. Erstens ist SSH relativ einfach einzurichten - SSH-Daemons sind an der Tagesordnung, viele Netzwerkadministratoren haben Erfahrung damit, und viele Betriebssystem-Distributionen werden mit ihnen eingerichtet oder verfügen über Tools, um sie zu verwalten. Als nächstes ist der Zugriff über SSH sicher - die gesamte Datenübertragung wird verschlüsselt und authentifiziert. Wie die Protokolle HTTPS, Git und Local ist auch SSH effizient und sorgt dafür, dass die Daten vor der Übertragung so kompakt wie möglich sind.

Die Nachteile

Der negative Aspekt von SSH ist, dass es keinen anonymen Zugriff auf Ihr Git-Repository unterstützt. Wenn Sie SSH verwenden, müssen Benutzer über SSH-Zugriff auf Ihren Computer verfügen, auch wenn sie nur über Lesezugriff verfügen. Dies macht SSH nicht für Open Source-Projekte geeignet, für die Benutzer möglicherweise einfach Ihr Repository klonen möchten, um es zu überprüfen. Wenn Sie es nur in Ihrem Unternehmensnetzwerk verwenden, ist SSH möglicherweise das einzige Protokoll, mit dem Sie sich befassen müssen. Wenn Sie anonymen schreibgeschützten Zugriff auf Ihre Projekte und die Verwendung von SSH zulassen möchten, müssen Sie SSH einrichten, damit Sie Push-over ausführen können, jedoch etwas anderes, von dem andere Benutzer abrufen können.

Weitere Informationen finden Sie in der Referenz: Git auf dem Server - Die Protokolle

2
Amirhossein72

Sie müssen ein Verzeichnis auf einem Remote-Server erstellen. Verwenden Sie dann den Befehl "git init", um es als Repository festzulegen. Dies sollte für jedes neue Projekt durchgeführt werden, das Sie haben (jeder neue Ordner)

Angenommen, Sie haben git bereits mit ssh-Schlüsseln eingerichtet und verwendet, dann habe ich ein kleines Python Skript geschrieben, das, wenn es aus einem Arbeitsverzeichnis ausgeführt wird, ein Remote-Verzeichnis erstellt und das Verzeichnis als git repo initialisiert Natürlich müssen Sie das Skript (nur einmal) bearbeiten, um es dem Server und dem Root-Pfad für alle Repositorys mitzuteilen.

Überprüfen Sie hier - https://github.com/skbobade/ocgi

2
Sam

Es gibt einen interessanten Unterschied zwischen den beiden oben genannten gängigen Lösungen:

  1. Wenn Sie das Bare-Repository folgendermaßen erstellen:

     cd /outside_of_any_repo[.____.₱mkdir my_remote.git 
     cd my_remote.git 
     git init --bare 
    

und dann

cd  /your_path/original_repo
git remote add Origin /outside_of_any_repo/my_remote.git
git Push --set-upstream Origin master

Dann richtet git die Konfiguration in 'original_repo' mit dieser Beziehung ein:

original_repo Origin --> /outside_of_any_repo/my_remote.git/

mit letzterer als vorgelagerter Gegenstelle. Und die Upstream-Fernbedienung hat keine anderen Fernbedienungen in ihrer Konfiguration.

  1. Wenn Sie es jedoch anders herum machen:

     (aus dem Verzeichnis original_repo) 
     cd .. 
     git clone --bare original_repo /outside_of_any_repo/my_remote.git
    

dann wird 'my_remote.git' mit seiner Konfiguration beendet, bei der 'Origin' auf 'original_repo' als Remote verweist, wobei eine remote.Origin.url dem lokalen Verzeichnispfad entspricht, was möglicherweise nicht angebracht ist, wenn sie verschoben werden soll zu einem Server.

Obwohl diese "Remote" -Referenz später leicht entfernt werden kann, wenn sie nicht geeignet ist, muss "original_repo" immer noch so eingerichtet werden, dass sie auf "my_remote.git" als Upstream-Remote verweist (oder auf einen beliebigen Ort) geteilt werden von). Technisch gesehen können Sie mit Ansatz 2 mit ein paar weiteren Schritten zum gleichen Ergebnis gelangen. Nummer 1 scheint jedoch ein direkterer Ansatz zu sein, um ein "zentrales Bare-Shared-Repo" zu erstellen, das von einem lokalen Repo ausgeht und für den Umzug auf einen Server geeignet ist, wobei weniger Schritte erforderlich sind. Ich denke, es hängt von der Rolle ab, die das Remote-Repo spielen soll. (Und ja, das steht im Widerspruch zur Dokumentation hier .)

Vorsichtsmaßnahme: Ich habe dies (in diesem Artikel Anfang August 2019) gelernt, indem ich auf meinem lokalen System einen Test mit einem echten Repo durchgeführt und dann die Ergebnisse Datei für Datei verglichen habe. Aber! Ich lerne noch, also könnte es einen richtigeren Weg geben. Meine Tests haben mir jedoch zu dem Schluss verholfen, dass die Nummer 1 meine derzeit bevorzugte Methode ist.

2
V. Wheeler