GIT clone repo sur le système de fichiers local dans Windows
Je suis un Noob complet quand il s'agit de GIT. Je viens de faire mes premiers pas ces derniers jours. J'ai installé un dépôt sur mon ordinateur portable, j'ai tiré le coffre d'un projet SVN (quelques problèmes avec les branches, mais ils ne fonctionnaient pas), mais tout semble aller pour le mieux.
Je veux maintenant pouvoir tirer ou pousser de l'ordinateur portable à mon bureau principal. La raison en est que 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. Donc, je veux être capable de pousser/tirer de l'ordinateur portable vers l'ordinateur principal lorsque je rentre à la maison. Je pensais que le moyen le plus simple d'y parvenir serait simplement de partager le dossier de code sur le réseau local et de:
git clone file://192.168.10.51/code
malheureusement, cela ne semble pas fonctionner pour moi:
donc j'ouvre un cmd bash git et tapez la commande ci-dessus, je suis dans C:\code (le dossier partagé pour les deux machines) voici 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 puis-je 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 endroits où les autres développeurs, le serveur CI, etc. vont puiser, c'est simplement pour que je puisse travailler sur le même référentiel sur deux machines.
Selon la suggestion de Sebastian, je reçois 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ÉPONSE **
Merci à tout ce qui a 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 était:
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 nécessite l'utilisation de quatre barres obliques:
git clone file:////<Host>/<share>/<path>
Par exemple, si votre ordinateur principal a l’adresse IP 192.168.10.51 et le nom de l’ordinateur main, et qu’il possède un partage nommé code _ qui est lui-même 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 se trouve 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, il s’agit (le répertoire C:/path/to/repo contient le répertoire .git):
C:\some\dir\> git clone --local file:///C:/path/to/repo my_project
Le référentiel sera clone sur C:\some\dir\my_project. Si vous omettez la partie file:///, alors l'option --local 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 avec 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, ce que vous pouvez voir à cause de la partie/cygdrive/c dans mes chemins. Avec quelques ajustements sur le chemin, cela devrait fonctionner avec n'importe quelle installation de git.
Ajouter une télécommande fonctionne de la même manière
git remote add remotename file:///cygdrive/c/path/to/repository/
Peut-être mapper le partage en tant que lecteur réseau puis faire
git clone Z:\
Surtout juste une supposition; Je fais toujours ce genre de choses en utilisant ssh. En tenant compte de cette suggestion, vous devrez bien sûr mapper ce lecteur à chaque fois que vous poussez/tirez vers/depuis l'ordinateur portable. Je ne suis pas sûr de savoir comment vous pouvez installer ssh pour travailler sous windows, mais si vous envisagez de le faire souvent, cela peut valoir la peine d’enquêter.
Pas sûr que ce soit à cause de ma version de Git (1.7.2) ou quoi, mais les approches énumérées ci-dessus 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 repo était un repo nu que j'avais initialisé et poussé à partir d'une machine différente.
J'essayais de cloner project1 comme indiqué ci-dessus avec des commandes telles que:
$ 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
Qu'est-ce que a fait pour moi était quelque chose de plus simple:
$ git clone ../git/project1
Cloning into project1...
done.
Remarque - même si le référentiel copié était nu, cela produisait un clone "normal" avec tous les fichiers de code/image/ressources que j'espérais (par opposition aux éléments internes du référentiel git).
Entrez des chemins absolus ou relatifs.
Par exemple, le premier ci-dessous utilise des chemins absolus:
(Cela provient 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à quoi que ce soit. et s'il n'est pas présent, un nouveau dossier sera créé)
~/git$ git clone --no-hardlinks ~/git/git_test1/ ~/git/bkp_repos/
Ce qui suit utilise des chemins relatifs:
~/git$ git clone --no-hardlinks git_test1/ bkp_repos2/
Notez que depuis 2016 et le MingW-64 _git.exe_ emballé avec Git pour Windows , un chemin UNC est pris en charge.
(Voir " Comment msys, msys2 et MinGW-64 sont-ils liés? ")
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 9e9da2 , commit 5440df4 (17 janvier 2019) par Johannes Schindelin (dscho) .
Aidé de: Kim Gybels (_Jeff-G_) .
(Fusionnée par Junio C Hamano - gitster - dans commit f5dd919 , 5 février 2019)
Avant Git 2.21, à cause d'un caprice dans la méthode de Git de générer _git-upload-pack_, il existe un problème lors du passage de chemins contenant des barres obliques inverses: Git forcera la ligne de commande à travers le shell, qui a une sémantique différente dans Git pour Windows (étant un programme MSYS2) que les exécutables Win32 normaux tels que _git.exe_ lui-même.
Le symptôme est que la première des deux barres obliques inverses dans les chemins UNC de la forme _\\myserver\folder\repository.git_ est supprimée .
Ceci est atténué maintenant:
mingw: arguments de cas spéciaux pour
shLe runtime MSYS2 fait de son mieux pour émuler le développement des caractères génériques en ligne de commande et les annotations qui seraient effectuées par le shell Unix appelant sur les systèmes Unix.
Ces règles de citation de shell Unix diffèrent des règles de citation s'appliquant aux commandes cmd et Powershell de Windows, ce qui rend un peu délicat de citer correctement les paramètres de ligne de commande lors du lancement d'autres processus.
En particulier, _
git.exe_ passe les arguments aux sous-processus dont ne sont pas destinés à être interprétés comme des caractères génériques, et s'ils contiennent des barres obliques inverses, ils ne doivent pas être interprété comme un caractère d'échappement, par exemple en passant par les chemins Windows.Remarque: cela ne pose un problème que lorsque vous appelez des exécutables MSYS2, et non lorsque vous appelez des exécutables MINGW tels que git.exe. Toutefois, nous appelons fréquemment les exécutables MSYS2, notamment lorsque vous définissez l'indicateur _
use_Shell_ dans la structure child_process.Il n’existe aucun moyen élégant de déterminer si le fichier _
.exe_ à exécuter est un programme MSYS2 ou un programme 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 de _sh.exe_.Introduisons un test moche et codé en dur si _
argv[0]_ est "sh", et s'il fait référence au bash MSYS2, afin de déterminer s'il est nécessaire de citer les arguments différemment.Cela ne résout toujours pas le problème complètement, mais au moins c'est quelque chose.
Incidemment, cela résout également le problème où _
git clone \\server\repo_ a échoué en raison d'une gestion incorrecte des barres obliques inverses lors du transfert du chemin d'accès au processus _git-upload-pack_.De plus, nous devons prendre soin de ne pas seulement citer les espaces et les barres obliques inverses, mais également les accolades.
Comme les alias passent souvent par le MSYS2 Bash et qu’ils obtiennent fréquemment des paramètres tels que _HEAD@{yesterday}_, c’est vraiment important.