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

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

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

$ 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.

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/

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/

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é.

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).

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/

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

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