Tenter quelque chose comme git clone git://github.com/ry/node.git
ne fonctionnera pas, il en résultera:
Initialized empty Git repository in /home/robert/node/.git/
github.com[0: 207.97.227.239]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)
Cependant, le clonage via HTTP fonctionne bien. Jusqu'à présent, j'ai compris qu'il y avait un problème avec le protocole, mais j'essaie d'installer cloud9 qui requiert la commande
git submodule update --init --recursive
qui essaie d'utiliser le protocole git: // et échoue. Existe-t-il un moyen de changer le fonctionnement de cette commande?
S'il s'agit d'un problème lié au blocage du port git: protocol par votre pare-feu (9418), vous devez effectuer une modification plus persistante afin de ne pas avoir à vous rappeler de donner des commandes suggérées par d'autres publications pour chaque dépôt Git.
La solution ci-dessous ne fonctionne que pour les sous-modules qui pourraient également utiliser le protocole git:.
Comme le message git ne pointe pas directement vers le port 9418 bloquant le pare-feu, essayons de diagnostiquer le problème comme tel.
Références: https://superuser.com/q/621870/203918 et https://unix.stackexchange.com/q/11756/57414
Il existe plusieurs outils que nous pouvons utiliser pour déterminer si le pare-feu à l'origine de notre problème - utilisez celui qui est installé sur votre système.
# Using nmap
# A state of "filtered" against port 9418 (git) means
# that traffic is being filtered by a firewall
$ nmap github.com -p http,git
Starting Nmap 5.21 ( http://nmap.org ) at 2015-01-21 10:55 ACDT
Nmap scan report for github.com (192.30.252.131)
Host is up (0.24s latency).
PORT STATE SERVICE
80/tcp open http
9418/tcp filtered git
# Using Netcat:
# Returns 0 if the git protocol port IS NOT blocked
# Returns 1 if the git protocol port IS blocked
$ nc github.com 9418 < /dev/null; echo $?
1
# Using CURL
# Returns an exit code of (7) if the git protocol port IS blocked
# Returns no output if the git protocol port IS NOT blocked
$ curl http://github.com:9418
curl: (7) couldn't connect to Host
OK, alors maintenant nous avons déterminé que notre port git était bloqué par un pare-feu, que pouvons-nous faire à ce sujet? Continuer à lire :)
Git fournit un moyen de réécrire les URL en utilisant git config
. Émettez simplement la commande suivante:
git config --global url."https://".insteadOf git://
Maintenant, comme par magie, toutes les commandes git effectueront une substitution de git://
à https://
Jetez un coup d’œil à votre configuration globale en utilisant:
git config --list
Vous verrez la ligne suivante dans la sortie:
url.https://.insteadof=git://
Vous pouvez voir à quoi ça ressemble dans le fichier, en jetant un coup d’œil à ~/.gitconfig
où vous devriez maintenant voir que les deux lignes suivantes ont été ajoutées:
[url "https://"]
insteadOf = git://
Utilisez simplement une URL plus complète/spécifique dans le remplacement. Par exemple, pour avoir uniquement les URL GitHub, utilisez https: // au lieu de git: //, vous pouvez utiliser quelque chose comme:
git config --global url."https://github".insteadOf git://github
Vous pouvez exécuter cette commande plusieurs fois en utilisant différents remplacements. Toutefois, dans le cas où une URL correspond à plusieurs remplacements, la correspondance la plus longue "gagne". Un seul remplacement sera effectué par URL.
Si vous êtes un administrateur système Linux et que vous ne voulez pas que vos utilisateurs aient à passer par les difficultés ci-dessus, vous pouvez modifier rapidement la configuration de git à l'échelle du système.
Modifiez simplement ou ajoutez le contenu suivant à /etc/gitconfig
et voila vos utilisateurs n'ont pas à s'inquiéter de ce qui précède:
[url "https://"]
insteadOf = git://
Github fournit également un accès http (s), ce qui est beaucoup moins susceptible d'être bloqué par votre entreprise. Pour dire au sous-module de l'utiliser, vous pouvez faire ceci:
git submodule init
git config submodule.<name>.url https://github.com/...
git submodule update
C’est en fait exactement pourquoi init et update sont des commandes distinctes: vous pouvez init, personnaliser les emplacements, puis mettre à jour. update --init
n'est qu'un raccourci pour ne pas avoir besoin de personnaliser les URL.
Pour tous ceux qui y surviennent, vous pouvez bien sûr également utiliser une URL ssh (si votre société bloque git: // mais pas ssh), mais dans ce cas, l'OP n'a probablement pas d'accès SSH au référentiel distant.
Une autre option qui n’implique pas de toucher à git config est de changer les paramètres ssh pour utiliser le port 443 au lieu du port 22 habituel.
Référence: tilisation de SSH sur le port HTTPS
De cet article:
edit the file at ~/.ssh/config, and add this section:
Host github.com
Hostname ssh.github.com
Port 443
Ensuite, j'ai réussi à git Push to Github. À la maison, vous pouvez changer la configuration ssh comme si elle était.
J'avais aussi le même problème pendant un moment. Ensuite, j'ai essayé de changer la configuration de git en utilisant la commande suggérée:
git config --global url."https://".insteadOf git://
qui malheureusement n'a pas fait l'affaire pour moi. J'avais toujours le même problème!
Ce qui a finalement résolu mon problème, c’est que j’ai de nouveau réinitialisé l’url distante de mon référentiel à l’aide de la commande suivante:
git remote set-url Origin https://github.com/<my_user_name>/<my_repo_name>.git
qui était auparavant comme ceci:
git remote set-url Origin [email protected]:<my_user_name>/<my_repo_name>.git
Après avoir défini l’URL distante avec https://
au lieu de [email protected]
le problème a été résolu pour moi.
En développant la réponse de Nathan ci-dessus, vous pouvez également essayer le protocole ssh si le pare-feu de votre entreprise interfère avec https. Dans mon cas, le pare-feu bloquait le protocole git, réémettait des certificats SSL pour https et cela rompait le foutoir pour moi, même si l'option strict-ssl était désactivée. Vous pouvez faire une réécriture d'URL similaire pour ssh et créer une clé/paire ssh comme décrit sur github .
git config --global url."ssh://[email protected]".insteadOf git://github.com
Vous devrez également allumer le ssh-agent pour votre installation git.
c'est parce que l'adresse GIT du serveur de noeud a changé, vous devez entrer maintenant:
clone de git https://github.com/joyent/node
bonne chance
J'ajouterai ici ma propre approche (, qui n'est pas requise si vous avez un référentiel git accessible au public qui prend en charge https ).
Je travaille dans une entreprise où le référentiel git n'est accessible que depuis l'intérieur de l'entreprise. Mais je travaille aussi de la maison.
J'ai créé un référentiel avec un dossier sur mon lecteur google. Sauf pour git et https, vous pouvez inclure des référentiels sous forme de chemins.
Donc, au lieu de pousser sur Origin I Push vers "gDrive". Cela provoque la synchronisation du dossier de mon poste de travail à domicile sur Google Drive, puis mon ordinateur de travail extrait les modifications. De plus, comme les fichiers du répertoire ".git" ne sont parfois pas synchronisés, je le renomme temporairement, par exemple. "tronc" à "trunk2". Cela oblige les ordinateurs domestiques et professionnels à être synchronisés à 100% avec Google Drive.
Je me connecte ensuite à mon ordinateur de travail via checkpoint-vpn remote (ou teamviewer) et envoie mes mises à jour au référentiel git de travail.