Dépôt de clone GIT sur le système de fichiers local dans Windows


200

Je suis un Noob complet en ce qui concerne GIT. Je viens de faire mes premiers pas ces derniers jours. J'ai installé un dépôt sur mon ordinateur portable, retiré le coffre d'un projet SVN (j'ai eu quelques problèmes avec les branches, je ne les ai pas fait fonctionner), mais tout semble bien là-bas.

Je veux maintenant pouvoir tirer ou pousser de l'ordinateur portable vers mon bureau principal. La raison d'être de l'ordinateur portable est pratique dans le train car je passe 2 heures par jour à voyager et je peux faire du bon travail. Mais ma machine principale à la maison est idéale pour le développement. Je veux donc pouvoir pousser / tirer de l'ordinateur portable vers l'ordinateur principal quand je rentre à la maison. Je pensais que la façon la plus simple de le faire serait de simplement partager le dossier de code sur le LAN et de faire:

git clone file://192.168.10.51/code

malheureusement cela ne semble pas fonctionner pour moi:

donc j'ouvre un cmd git bash et tape la commande ci-dessus, je suis en C: \ code (le dossier partagé pour les deux machines) c'est ce que je récupère:

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

Comment partager le référentiel entre les deux machines de la manière la plus simple.

Il y aura d'autres emplacements qui seront des points de stockage officiels et des emplacements d'où les autres développeurs et serveurs CI, etc. tireront, c'est juste pour que je puisse travailler sur le même dépôt sur deux machines.

Selon la suggestion de Sebastian, j'obtiens ce qui suit:

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

** MODIFIER - RÉPONDRE **

Merci à tous ceux qui ont aidé. J'ai essayé de mapper un lecteur et cela a fonctionné, alors j'ai pensé revenir en arrière et réessayer sans mappage. Le résultat final a été:

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

Cela a très bien fonctionné.

Merci


file: //192.168.10.51/code n'est en aucun cas un URI valide pointant vers un fichier, alors que file: // C: \ foo \ bar.txt est
Gregory Pakosz

Alors, comment puis-je pointer vers une machine distante avec une telle référence?
Jon

Vous souhaitez probablement mapper un lecteur réseau.
Josh Lee

a fonctionné pour moi - notez que cela est spécifique aux fenêtres et ne fonctionnera pas à partir de git bash dans les fenêtres - devez utiliser cmd ou powershell
Dave Rael

également essayé en cmd mais ça ne marche pas. Et qu'est-ce que le "code" dans le fichier "git clone: ​​// \\\\ 192.168.0.51 \ code"? Je l'ai remplacé par "C: / UniserverZ / www / sampleProject /" et cela n'a pas fonctionné. Il a dit que ce n'était pas un dépôt git
boi_echos

Réponses:


177

Vous pouvez spécifier l'URL de la télécommande en appliquant le chemin UNC au protocole de fichier. Cela vous oblige à utiliser quatre barres obliques:

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

Par exemple, si votre machine principale a l'IP 192.168.10.51 et le nom de l'ordinateur main, et qu'elle a un partage nommé codequi lui-même est un référentiel git, les deux commandes suivantes devraient fonctionner de la même manière:

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

Si le référentiel Git est dans un sous-répertoire, ajoutez simplement le chemin:

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

2
existe-t-il un moyen de s'authentifier (c'est-à-dire nom d'utilisateur / mot de passe) avec ce schéma?
intuition

1
@majgis J'utilise presque uniquement Windows, donc ma solution fonctionne pour Windows.
poke

1
oui, c'est la meilleure façon de le faire dans les fenêtres.
Nicholas DiPiazza

3
On pourrait également utiliser le protocole: //// utilisateur: mot de passe @ hôte: notation port / chemin , par exemple: fichier: /// utilisateur: mot de
passe@192.168.10.51/code

1
@OderWat Sauf que l'utilisation de localhost ne vous aidera pas du tout lorsque vous essayez d'accéder à un autre ordinateur, ce qui était la question. Si vous voulez accéder à un référentiel local , c'est-à-dire qui existe localement dans votre système de fichiers, vous pouvez simplement utiliser un chemin local sans utiliser le protocole de fichier…
poke

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

La commande ci-dessus utilise la notation de chemin POSIX pour le répertoire avec votre référentiel git. Pour Windows, c'est (le répertoire C:/path/to/repocontient le .gitrépertoire):

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

Le référentiel sera cloné dans C:\some\dir\my_project. Si vous omettez une file:///partie, l' --localoption est implicite.


7
Cela a fonctionné pour moi pour les chemins de fichiers avec des espaces: git clone -l fichier: // "C: \ SOME PATH \ WITH SPACES" my_project
Sebastian Patten

1
Grande aide. Cela fonctionne pour moi dans ma machine Windows 7. <à partir de l'invite de commande git bash> quelque chose comme: fichier de clonage git: /// C: / Users / username / repsitoryName
Forhad

vous voudrez probablement régler la télécommande par la suite .. sinon elle pointe vers votre autre local comme origine que je trouve super sujette aux erreurs. utilisez git remote -v, git remote rm origin; git add origin <repo-address> (que vous pouvez copier après avoir fait git remote -v sur le dépôt local d'origine)
Hanan

C'est correct, vous n'avez pas besoin d'utiliser un formulaire url comme file: ////, vous pouvez simplement cloner un répertoire.
Peter N. Steinmetz

14

la réponse avec le nom d'hôte n'a pas fonctionné pour moi, mais cela a fonctionné:

fichier de clonage git: ////home/git/repositories/MyProject.git/


1
Il semble que vous ayez trop de barres obliques après "fichier:". Pour moi, le nombre magique était de 3 barres obliques
Mark F Guerra

Bizarre. Quatre barres obliques m'ont donné une erreur fatale. Cela ne fonctionnait (pour moi) qu'avec trois.
Big McLargeHuge

4
Mon astuce pour comprendre la syntaxe qui fonctionne est de créer un fichier txt dans le dossier et de le faire glisser pour l'ouvrir dans le navigateur. L'URL correcte pour un fichier apparaît.
AnneTheAgile

7

J'ai réussi à le faire en utilisant file: //, mais avec une barre oblique supplémentaire pour indiquer un chemin absolu.

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

Dans mon cas, j'utilise Git sur Cygwin pour Windows, que vous pouvez voir à cause de la partie / cygdrive / c dans mes chemins. Avec quelques ajustements au chemin, cela devrait fonctionner avec n'importe quelle installation de git.

L'ajout d'une télécommande fonctionne de la même manière

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

6

Peut-être mappez le partage en tant que lecteur réseau, puis faites

git clone Z:\

Surtout juste une supposition; Je fais toujours ce genre de choses en utilisant ssh. Suivre cette suggestion signifie bien sûr que vous devrez mapper ce lecteur à chaque fois que vous poussez / tirez vers / depuis l'ordinateur portable. Je ne sais pas comment vous configurez ssh pour travailler sous Windows, mais si vous allez faire cela beaucoup, cela pourrait valoir la peine d'être étudié.


@Carlos: Je pense que cela ne fonctionnera que si vous ne l'avez pas fait cddans un autre répertoire du Z:lecteur. IIRC; Je n'ai pas été un utilisateur Windows depuis un certain temps. Il se peut également que gitles lettres de lecteur soient interprétées différemment de la convention Windows standard. Avez-vous essayé `Z:`?
intuition

errr ... qui aurait dû lire "avez-vous essayé` Z: \ `?". Eh bien, sauf avec un échappement correct pour que le mode code soit activé .. #nurrrr .. Je suppose que non, de toute façon.
intuition

3

Je ne sais pas si c'était à cause de ma version git (1.7.2) ou quoi, mais les approches répertoriées ci-dessus en utilisant le nom de la machine et les options IP ne fonctionnaient pas pour moi. Un détail supplémentaire qui peut / peut ne pas être important est que le référentiel était un référentiel nu que j'avais initialisé et poussé depuis une autre machine.

J'essayais de cloner project1 comme indiqué ci-dessus avec des commandes comme:

$ 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

et

$ 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

Ce qui a fonctionné pour moi était quelque chose de plus simple:

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

Remarque - même si le dépôt à partir duquel le clonage a été cloné était nu, cela a produit un clone `` normal '' avec tous les fichiers de code / image / ressources réels que j'espérais (par opposition aux internes du dépôt git).


1

Entrez des chemins absolus ou des chemins relatifs.

Par exemple, le premier ci-dessous utilise des chemins absolus:

(c'est de l'intérieur du dossier qui contient le référentiel et la sauvegarde en tant que sous-dossiers. rappelez-vous également que le dossier de sauvegarde n'est pas modifié s'il contient déjà quelque chose. et s'il n'est pas présent, un nouveau dossier sera créé)

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

Les éléments suivants utilisent des chemins relatifs:

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

0

Alors que le chemin UNC est pris en charge depuis Git 2.21 (février 2019, voir ci-dessous), Git 2.24 (Q4 2019) permettra

git clone file://192.168.10.51/code

Pas plus file:////xxx' file://' suffit pour faire référence à un partage de chemin UNC.
Voir " Erreur de récupération Git avec UNC ".


Notez que depuis 2016 et le MingW-64 fourni git.exe avec Git pour Windows , un chemin UNC est pris en charge.
(Voir " Comment les msys, msys2 et MinGW-64 sont-ils liés les uns aux autres? ")

Et avec Git 2.21 (février 2019), cette prise en charge s'étend même dans un shell msys2 (avec des guillemets autour du chemin UNC).

Voir commit 9e9da23 , commit 5440df4 (17 janvier 2019) par Johannes Schindelin ( dscho) .
Aidé par: Kim Gybels ( Jeff-G) .
(Fusionné par Junio ​​C Hamano - gitster- en commit f5dd919 , 05 févr.2019 )

Avant Git 2.21, en raison d'une bizarrerie dans la méthode de Git pour git-upload-packapparaître, il y a un problème lors du passage de chemins avec des barres obliques inverses: Git forcera la ligne de commande à travers le shell, qui a une sémantique de guillemets différente dans Git pour Windows (étant un MSYS2 programme) que les exécutables Win32 classiques tels que git.exelui-même.

Le symptôme est que la première des deux barres obliques inverses dans les chemins UNC du formulaire \\myserver\folder\repository.gitest supprimée .

Ceci est maintenant atténué:

mingw: arguments spéciaux pour sh

Le runtime MSYS2 fait de son mieux pour émuler l'expansion et la suppression de guillemets en ligne de commande qui seraient effectuées par le shell Unix appelant sur les systèmes Unix.

Ces règles de citation du shell Unix diffèrent des règles de citation applicables aux cmd et Powershell de Windows, ce qui rend un peu gênant la citation correcte des paramètres de ligne de commande lors de la génération d'autres processus.

En particulier, git.exetransmet des arguments à des sous-processus qui ne sont pas destinés à être interprétés comme des caractères génériques, et s'ils contiennent des barres obliques inverses, ceux-ci ne doivent pas être interprétés comme des caractères d'échappement, par exemple lors du passage de chemins Windows.

Remarque: il s'agit uniquement d'un problème lors de l'appel d'exécutables MSYS2, pas lors de l'appel d'exécutables MINGW tels que git.exe. Cependant, nous appelons fréquemment les exécutables MSYS2, notamment lors de la définition de l' use_shellindicateur dans la structure child_process.

Il n'existe aucun moyen élégant de déterminer si le .exefichier à exécuter est un programme MSYS2 ou MINGW.
Mais comme le cas d'utilisation du passage d'une ligne de commande à travers le shell est si répandu, nous devons contourner ce problème au moins lors de l'exécution sh.exe.

Introduisons un test laid et codé en dur pour savoir si argv[0]" sh", et s'il fait référence au MSYS2 Bash, pour déterminer si nous devons citer les arguments différemment que d'habitude.

Cela ne résout toujours pas complètement le problème, mais au moins c'est quelque chose.

Par ailleurs, cela résout également le problème en cas d' git clone \\server\repoéchec en raison d'une gestion incorrecte des barres obliques inverses lors de la remise du chemin d'accès au git-upload-packprocessus.

De plus, nous devons prendre soin de citer non seulement les espaces et les barres obliques inverses, mais aussi les accolades.
Comme les alias passent fréquemment par le Bash MSYS2, et comme les alias obtiennent fréquemment des paramètres tels que HEAD@{yesterday}, cela est vraiment important.

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


0

Après le clone, pour moi, push ne fonctionnait pas.

Solution: où le référentiel est cloné, ouvrez le dossier .git et le fichier de configuration.

Pour la valeur de réglage de l'URL d'origine distante:

[remote "origin"]
    url = file:///C:/Documentation/git_server/kurmisoftware
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.