wake-up-neo.com

GIT Clone 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 von 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 praktisch im Zug ist, da ich 2 Stunden am Tag unterwegs bin und gute Arbeit leisten kann. Aber meine Hauptmaschine zu Hause ist großartig für die Entwicklung. Ich möchte also in der Lage sein, vom Laptop auf den Hauptcomputer zu drücken/zu ziehen, wenn ich zu Hause bin. Ich dachte, die einfachste Möglichkeit wäre, den Code-Ordner ü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 eine git bash cmd und tippe den obigen Befehl ein. Ich befinde mich in C:\code (dem freigegebenen Ordner für beide Maschinen). 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 teilen?.

Es wird andere Speicherorte geben, an denen die anderen Entwickler, der CI-Server usw. abgelegt werden. Dies dient nur dazu, dass ich auf zwei Computern an demselben Repo arbeiten kann.

Auf Sebastians Vorschlag hin 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 - ANTWORTEN **

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

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

Das hat super funktioniert.

Vielen Dank

199
Jon

Sie können die URL der Fernbedienung angeben, indem Sie den Pfad UNC zum Dateiprotokoll angeben. 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 main hat und eine Freigabe mit dem Namen code, das selbst ein Git-Repository ist, dann sollten beide der folgenden Befehle gleich 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 an:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository
177
poke
$ 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/repo Enthält .git Verzeichnis):

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

Das Repository wird auf C:\some\dir\my_project Geklont. Wenn Sie den Teil file:/// Weglassen, ist die Option --local Impliziert.

123
jfs

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

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

14
Talaat Safwat

Dies gelang mir mit file: //, 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 sich aus dem/cygdrive/c-Teil in meinen Pfaden ergibt. Mit einigen Änderungen 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/
7
Mark F Guerra

Vielleicht die Freigabe als Netzlaufwerk zuordnen und dann tun

git clone Z:\

Meist nur eine Vermutung; Ich mache das immer mit ssh. Wenn Sie diesem Vorschlag folgen, müssen Sie dieses Laufwerk natürlich jedes Mal zuordnen, wenn Sie auf den Laptop drücken oder von ihm ziehen. Ich bin mir nicht sicher, wie Sie ssh für die Arbeit unter Windows aufrüsten, aber wenn Sie dies häufig tun, könnte es sich lohnen, nachzuforschen.

6
intuited

Ich bin mir nicht sicher, ob es an meiner Git-Version (1.7.2) lag oder nicht, aber die oben aufgeführten Ansätze, bei denen der Computername und die IP-Optionen verwendet wurden, haben bei mir nicht funktioniert. Ein zusätzliches Detail, das möglicherweise/möglicherweise nicht wichtig ist, ist, dass das Repo ein nacktes Repo war, das ich initialisiert und von einem anderen Computer auf das Repo verschoben hatte.

Ich habe versucht, project1 wie oben beschrieben mit Befehlen wie den folgenden 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 hat für mich funktioniert war etwas einfacher:

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

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

3
bargar

Geben Sie entweder absolute oder relative Pfade ein.

Das erste Beispiel unten verwendet absolute Pfade:

(Dies ist aus dem Ordner, 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/

Das Folgende verwendet relative Pfade:

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

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

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

Siehe commit 9e9da2 , commit 5440df4 (17. Januar 2019) von Johannes Schindelin (dscho .
Geholfen von: Kim Gybels (Jeff-G) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Commit f5dd919 , 05. Februar 2019)

Vor Git 2.21 gab es aufgrund einer Kuriosität in der Methode von Git, git-upload-pack Zu erzeugen, ein Problem beim Übergeben von Pfaden mit Backslashes: Git erzwingt die Befehlszeile durch die Shell, die in Git eine andere Anführungssemantik hat für Windows (als MSYS2-Programm) als normale ausführbare Win32-Dateien wie git.exe selbst.

Das Symptom ist, dass der erste der beiden Backslashes in UNC-Pfaden der Form \\myserver\folder\repository.git Entfernt wird .

Dies wird jetzt gemildert:

mingw: Sonderfallargumente zu sh

Die MSYS2-Laufzeitumgebung emuliert nach besten Kräften die Erweiterung und Aufhebung der Anführungszeichen in der Befehlszeile, die von der aufrufenden Unix-Shell auf Unix-Systemen ausgeführt wird.

Diese Unix-Shell-Anführungsregeln unterscheiden sich von den Anführungsregeln für Windows 'cmd und Powershell, so dass es etwas umständlich ist, Befehlszeilenparameter richtig anzugeben, wenn andere Prozesse erzeugt werden.

Insbesondere übergibt git.exe Argumente an Unterprozesse, die nicht als Platzhalter interpretiert werden sollen, und wenn sie umgekehrte Schrägstriche enthalten, sind dies keine als Fluchtzeichen zu interpretieren, z beim Übergeben von Windows-Pfaden.

Hinweis: Dies ist nur ein Problem beim Aufrufen von ausführbaren MSYS2-Dateien, nicht beim Aufrufen von ausführbaren MINGW-Dateien wie git.exe. Wir rufen jedoch häufig ausführbare MSYS2-Dateien auf, insbesondere wenn Sie das Flag use_Shell In der Struktur child_process setzen.

Es gibt keine elegante Möglichkeit, festzustellen, ob die auszuführende Datei .exe Ein MSYS2-Programm oder ein MINGW-Programm ist.
Aber da der Anwendungsfall, eine Befehlszeile über die Shell zu übergeben, so weit verbreitet ist, müssen wir dieses Problem zumindest bei der Ausführung von sh.exe Umgehen.

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 git clone \\server\repo Aufgrund einer falschen Behandlung der Backslashes bei der Übergabe des Pfads an den git-upload-pack - Prozess fehlgeschlagen ist.

Außerdem müssen wir darauf achten, nicht nur Leerzeichen und Backslashes, sondern auch geschweifte Klammern zu zitieren.
Da Aliase häufig den MSYS2-Bash durchlaufen und Aliase häufig Parameter wie [email protected]{yesterday} Erhalten, ist dies sehr wichtig.

Siehe t/t5580-clone-Push-unc.sh

0
VonC