GIT-Klon-Repo über das lokale Dateisystem in Windows

Ich bin ein absoluter Noob, wenn es um GIT geht. Ich habe gerade meine ersten Schritte in den letzten Tagen gemacht. Ich habe ein Repo auf meinem Laptop eingerichtet, den Trunk aus einem SVN-Projekt heruntergezogen (hatte einige Probleme mit Zweigen, brachte sie nicht zum Laufen), aber dort scheint alles in Ordnung zu sein.

Ich möchte jetzt in der Lage sein, vom Laptop auf meinen Hauptdesktop zu ziehen oder zu schieben. Der Grund dafür ist, dass der Laptop im Zug praktisch ist, da ich 2 Stunden am Tag unterwegs bin und gute Arbeit leisten kann. Aber meine Hauptmaschine zu Hause eignet sich hervorragend für die Entwicklung. Ich möchte also in der Lage sein, vom Laptop zum Hauptcomputer zu schieben / ziehen, wenn ich nach Hause komme. Ich dachte, der einfachste Weg, dies zu tun, wäre, einfach den Codeordner über das LAN freizugeben und Folgendes zu tun:

git clone file://192.168.10.51/code

Leider scheint das bei mir nicht zu funktionieren:

Also öffne ich ein Git Bash Cmd und gebe den obigen Befehl ein. Ich bin in C: \ Code (dem freigegebenen Ordner für beide Computer). Dies ist, was ich zurück bekomme:

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Wie kann ich das Repository auf einfachste Weise zwischen den beiden Computern freigeben?

Es wird andere Orte geben, die offizielle Speicherpunkte sind, und Orte, an denen die anderen Entwickler und CI-Server usw. abrufen. Dies ist nur so, dass ich auf zwei Computern an demselben Repo arbeiten kann.

Nach Sebastians Vorschlag bekomme ich folgendes:

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

** BEARBEITEN - ANTWORT **

Vielen Dank an alle, die geholfen haben. Ich habe versucht, ein Laufwerk zuzuordnen, und das hat funktioniert, sodass ich dachte, ich würde es ohne Zuordnung wiederholen. Das Endergebnis war:

git clone file://\\\\192.168.0.51\code

Das hat super geklappt.

Vielen Dank

Sie können die URL der Fernbedienung angeben, indem Sie den UNC- Pfad auf das Dateiprotokoll anwenden . Dazu müssen Sie vier Schrägstriche verwenden:

git clone file:////<host>/<share>/<path>

Wenn Ihr Hauptcomputer beispielsweise die IP 192.168.10.51 und den Computernamen mainhat und eine Freigabe mit dem Namen hat, codedie selbst ein Git-Repository ist, sollten beide der folgenden Befehle gleichermaßen funktionieren:

git clone file:////main/code
git clone file:////192.168.10.51/code

Wenn sich das Git-Repository in einem Unterverzeichnis befindet, fügen Sie einfach den Pfad hinzu:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository

$ git clone --no-hardlinks /path/to/repo

Der obige Befehl verwendet die POSIX-Pfadnotation für das Verzeichnis mit Ihrem Git-Repository. Für Windows ist es (Verzeichnis C:/path/to/repoenthält .gitVerzeichnis):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

Das Repository wird geklont C:\some\dir\my_project. Wenn Sie einen file:///Teil weglassen, ist die --localOption impliziert.

Die Antwort mit dem Hostnamen hat bei mir nicht funktioniert, aber das hat funktioniert:

Git-Klon-Datei: ////home/git/repositories/MyProject.git/

Es ist mir gelungen, dies mit file: // zu tun, aber mit einem zusätzlichen Schrägstrich, um einen absoluten Pfad zu kennzeichnen.

git clone file:///cygdrive/c/path/to/repository/

In meinem Fall verwende ich Git unter Cygwin für Windows, was Sie aufgrund des Teils / cygdrive / c in meinen Pfaden sehen können. Mit einigen Anpassungen am Pfad sollte es mit jeder Git-Installation funktionieren.

Das Hinzufügen einer Fernbedienung funktioniert genauso

git remote add remotename file:///cygdrive/c/path/to/repository/

Ordnen Sie die Freigabe möglicherweise einem Netzwerklaufwerk zu und tun Sie dies dann

git clone Z:\

Meist nur eine Vermutung; Ich mache dieses Zeug immer mit ssh. Wenn Sie diesem Vorschlag folgen, müssen Sie das Laufwerk natürlich jedes Mal zuordnen, wenn Sie auf den Laptop drücken / ziehen. Ich bin mir nicht sicher, wie Sie ssh für die Arbeit unter Windows einrichten, aber wenn Sie dies häufig tun, lohnt es sich möglicherweise, dies zu untersuchen.

Ich bin mir nicht sicher, ob es an meiner Git-Version (1.7.2) lag oder was, aber die oben aufgeführten Ansätze mit Computernamen und IP-Optionen funktionierten bei mir nicht. Ein zusätzliches Detail, das möglicherweise nicht wichtig ist, ist, dass das Repo ein reines Repo war, das ich von einem anderen Computer aus initialisiert und verschoben habe.

Ich habe versucht, project1 wie oben empfohlen mit folgenden Befehlen zu klonen:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

und

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Was tat für mich Arbeit war etwas einfacher:

$ git clone ../git/project1
Cloning into project1...
done.

Hinweis - Obwohl das Repo, von dem geklont wurde, leer war, wurde ein "normaler" Klon mit allen tatsächlichen Code- / Bild- / Ressourcendateien erstellt, auf die ich gehofft hatte (im Gegensatz zu den Interna des Git-Repos).

Geben Sie entweder absolute oder relative Pfade ein.

Zum Beispiel verwendet der erste unten absolute Pfade:

(Dies ist aus dem Ordner heraus, der das Repository und die Sicherung als Unterordner enthält. Denken Sie auch daran, dass der Sicherungsordner nicht geändert wird, wenn er bereits etwas enthält. Wenn er nicht vorhanden ist, wird ein neuer Ordner erstellt.)

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

Im Folgenden werden relative Pfade verwendet:

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/

Während der UNC-Pfad seit Git 2.21 (Februar 2019, siehe unten) unterstützt wird, ist Git 2.24 (Q4 2019) zulässig

git clone file://192.168.10.51/code

Nicht mehr file:////xxx' file://' reicht aus, um auf eine UNC-Pfadfreigabe zu verweisen.
Siehe " Git-Abruffehler mit UNC ".

Beachten Sie, dass seit 2016 und dem mit Git für Windows gepackten MingW-64 ein UNC-Pfad unterstützt wird. (Siehe " Wie hängen msys, msys2 und MinGW-64 zusammen? ")git.exe

Und mit Git 2.21 (Februar 2019) wird diese Unterstützung auch in einer msys2- Shell (mit Anführungszeichen um den UNC-Pfad) erweitert.

Siehe Commit 9e9da23 , Commit 5440df4 (17. Januar 2019) von Johannes Schindelin ( dscho) .
Mit freundlicher UnterstützungJeff-G von Kim Gybels ( ) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit f5dd919 , 05. Februar 2019)}

Vor Git 2.21 gibt es aufgrund einer Eigenart in Gits Spawn-Methode git-upload-packein Problem beim Übergeben von Pfaden mit Backslashes: Git erzwingt die Befehlszeile durch die Shell, die in Git für Windows eine andere Anführungszeichen-Semantik aufweist (MSYS2) Programm) als reguläre ausführbare Win32-Dateien wie sich git.exeselbst.

Das Symptom ist , dass die erste der beiden umgekehrten Schrägstrichen in UNC Pfaden der Form \\myserver\folder\repository.gitwird abgezogen .

Dies wird jetzt gemildert:

mingw: Sonderfallargumente zu sh

Die MSYS2-Laufzeit versucht nach besten Kräften, die Befehlszeilen-Platzhaltererweiterung und -Demotierung zu emulieren, die von der aufrufenden Unix-Shell auf Unix-Systemen ausgeführt wird.

Diese Anführungsregeln für die Unix-Shell unterscheiden sich von den Anführungsregeln für Windows cmd und Powershell, was es etwas umständlich macht, Befehlszeilenparameter beim Laichen anderer Prozesse richtig anzugeben.

Übergibt insbesondere git.exeArgumente an Unterprozesse, die nicht als Platzhalter interpretiert werden sollen. Wenn sie Backslashes enthalten, sind diese nicht als Escape-Zeichen zu interpretieren, z. B. beim Übergeben von Windows-Pfaden.

Hinweis: Dies ist nur beim Aufrufen von ausführbaren MSYS2-Dateien ein Problem, nicht beim Aufrufen von ausführbaren MINGW-Dateien wie git.exe. Wir rufen jedoch häufig ausführbare MSYS2-Dateien auf, insbesondere beim Setzen des use_shellFlags in der Struktur child_process.

Es gibt keine elegante Möglichkeit, festzustellen, ob es sich bei der .exeauszuführenden Datei um ein MSYS2-Programm oder ein MINGW-Programm handelt.
Da der Anwendungsfall des Übergebens einer Befehlszeile durch die Shell jedoch so weit verbreitet ist, müssen wir dieses Problem zumindest bei der Ausführung umgehen sh.exe.

Lassen Sie uns einen hässlichen, hartcodierten Test einführen, ob argv[0]" sh" ist und ob er sich auf den MSYS2-Bash bezieht, um festzustellen, ob wir die Argumente anders als gewöhnlich zitieren müssen.

Das behebt das Problem immer noch nicht vollständig, aber es ist zumindest etwas.

Dies behebt übrigens auch das Problem, bei dem ein git clone \\server\repoFehler aufgrund einer falschen Behandlung der Backslashes bei der Übergabe des Pfads an den git-upload-packProzess aufgetreten ist.

Außerdem müssen wir darauf achten, nicht nur Leerzeichen und Backslashes, sondern auch geschweifte Klammern anzugeben.
Da Aliase häufig den MSYS2-Bash durchlaufen und Aliase häufig Parameter wie erhalten HEAD@{yesterday}, ist dies sehr wichtig.

Sehen t/t5580-clone-push-unc.sh

Nach dem Klonen funktionierte Push für mich nicht.

Lösung: Wenn Repo geklont wird, öffnen Sie den .git-Ordner und die Konfigurationsdatei.

Für den Remote-Ursprungs-URL-Einstellwert:

[remote "origin"]
    url = file:///C:/Documentation/git_server/kurmisoftware