Próba czegoś takiego git clone git://github.com/ry/node.gitnie będzie działać, spowoduje to:

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)

Jednak klonowanie przez HTTP działa dobrze. Do tej pory zorientowałem się, że jest to problem z protokołem, ale próbuję zainstalować cloud9, który wymaga polecenia

git submodule update --init --recursive

który próbuje użyć protokołu git: // i kończy się niepowodzeniem. Czy istnieje sposób, aby zmienić sposób działania tego polecenia?

Jeśli jest to problem z zaporą blokującą port protokołu git: (9418), powinieneś wprowadzić bardziej trwałą zmianę, abyś nie musiał pamiętać o wydawaniu poleceń sugerowanych przez inne posty dla każdego repozytorium git.

Poniższe rozwiązanie działa również dla podmodułów, które mogą również korzystać z protokołu git:.

Ponieważ komunikat git tak naprawdę nie wskazuje natychmiast na port 9418 blokujący zaporę, spróbujmy zdiagnozować to jako rzeczywisty problem.

Diagnozowanie problemu

Odnośniki: https://superuser.com/q/621870/203918 i https://unix.stackexchange.com/q/11756/57414

Istnieje kilka narzędzi, których możemy użyć do ustalenia, czy zapora sieciowa powoduje nasz problem - użyj tego, które jest zainstalowane w twoim systemie.

# 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, teraz ustaliliśmy, że nasz port git jest blokowany przez zaporę ogniową. Co możemy z tym zrobić? Czytaj :)

Podstawowe przepisywanie adresów URL

Git zapewnia sposób na przepisywanie adresów URL za pomocą git config. Wystarczy wydać następujące polecenie:

git config --global url."https://".insteadOf git://

Teraz, jak za pomocą magii, wszystkie polecenia git wykonają zamianę git://nahttps://

Jakie zmiany wprowadziło to polecenie?

Spójrz na swoją globalną konfigurację, używając:

git config --list

W wyniku zobaczysz następujący wiersz:

url.https://.insteadof=git://

Możesz zobaczyć, jak to wygląda w pliku, sprawdzając, ~/.gitconfiggdzie powinieneś teraz zobaczyć, że dodano następujące dwie linie:

[url "https://"]
    insteadOf = git://

Chcesz więcej kontroli?

Po prostu użyj bardziej kompletnego / konkretnego adresu URL w zamianie. Na przykład, aby tylko adresy URL GitHub używały https: // zamiast git: //, możesz użyć czegoś takiego:

git config --global url."https://github".insteadOf git://github

Możesz uruchomić to polecenie wiele razy, używając różnych zamienników. Jednak w przypadku, gdy adres URL pasuje do wielu zamienników, najdłuższe dopasowanie „wygrywa”. Tylko jeden zamiennik zostanie wykonany na adres URL.

Systemowe zmiany dla Sysadmins

Jeśli jesteś Linux Sysadmin i nie chcesz, aby użytkownicy musieli przejść przez powyższe problemy, możesz dokonać szybkiej zmiany konfiguracji git w całym systemie.

Po prostu edytuj lub dodaj następującą treść, aby /etc/gitconfigużytkownicy nie musieli się martwić o żadne z powyższych:

[url "https://"]
    insteadOf = git://

Github zapewnia również dostęp do http (s), co jest znacznie mniej prawdopodobne, że zostanie zablokowane przez twoją firmę. Aby poinformować submoduł, aby tego używał, możesz to zrobić:

git submodule init
git config submodule.<name>.url https://github.com/...
git submodule update

Właśnie dlatego init i update są osobnymi poleceniami - możesz inicjować, dostosowywać lokalizacje, a następnie aktualizować. update --initjest tylko skrótem, gdy nie musisz dostosowywać żadnych adresów URL.

Każdemu innemu, kto się w tym stanie, możesz oczywiście użyć adresu URL ssh (jeśli Twoja firma blokuje git: //, ale nie ssh), ale w tym przypadku OP prawdopodobnie nie ma dostępu SSH do zdalnego repozytorium.

Inną opcją, która nie wymaga dotknięcia git config, jest zmiana ustawień ssh na użycie portu 443 zamiast zwykłego portu 22.

Odniesienie: Używanie SSH przez port HTTPS

Z tego artykułu:

edit the file at ~/.ssh/config, and add this section:

Host github.com
   Hostname ssh.github.com   
   Port 443

Później udało mi się skutecznie wypchnąć do Github. W domu możesz zmienić konfigurację ssh z powrotem na taką, jaka była, jeśli chcesz.

Przez jakiś czas miałem ten sam problem. Następnie próbowałem zmienić konfigurację git za pomocą sugerowanego polecenia:

git config --global url."https://".insteadOf git://

co niestety nie zadziałało dla mnie . Nadal miałem ten sam problem!

Tym, co faktycznie rozwiązało mój problem, jest zresetowanie zdalnego adresu URL mojego repozytorium za pomocą następującego polecenia:

git remote set-url origin https://github.com/<my_user_name>/<my_repo_name>.git

który wcześniej był taki:

git remote set-url origin git@github.com:<my_user_name>/<my_repo_name>.git

Po ustawieniu zdalnego adresu URL https://zamiast git@git.comproblemu został dla mnie rozwiązany.

Rozwijając powyższą odpowiedź Nathana, możesz również wypróbować protokół ssh, jeśli zapora firmowa zakłóca https. W moim przypadku zapora sieciowa blokowała protokół git, ponownie wystawiając certyfikaty ssl dla https i to dla mnie łamało, nawet przy wyłączonej opcji strict-ssl. Możesz wykonać podobną zmianę adresu URL dla ssh i utworzyć klucz / parę ssh, jak opisano na github .

 git config --global url."ssh://git@github.com".insteadOf git://github.com

Będziesz musiał także włączyć ssh-agent dla instalacji git.

to dlatego, że adres GIT dla serwera węzłów zmienił się, musisz teraz wprowadzić:

klon gita https://github.com/joyent/node

powodzenia

Wprowadzenie

Dodam tutaj moje własne podejście ( które nie jest wymagane, jeśli masz publicznie dostępne repozytorium git, które obsługuje https ).

Pracuję w firmie, w której repozytorium git jest dostępne tylko z wewnątrz firmy. Ale pracuję również z domu.

Jak przesłać do repozytorium firmowego z domu?

Utworzyłem repozytorium z folderem na moim dysku Google. Z wyjątkiem git i https można uwzględnić repozytoria jako ścieżki.

Zamiast naciskać na źródło, naciskam na „gDrive”. Powoduje to synchronizację folderu z mojej domowej stacji roboczej na dysk Google, a następnie mój komputer służbowy pobiera zmiany. Dodatkowo, ponieważ czasami pliki w katalogu „.git” nie synchronizują się, tymczasowo zmieniam nazwę folderu z np. „Trunk” na „trunk2”. Wymusza to 100% synchronizację komputerów domowych i służbowych z dyskiem Google.

Następnie loguję się na moim komputerze służbowym za pośrednictwem zdalnego kontrolera checkpoint-vpn (lub teamviewer) i wypycham moje aktualizacje do repozytorium git.

Dodatkowo proces działałby odwrotnie w przypadku wypychania do repozytorium git poza firmą, która jest zablokowana.

1. Przekaż ze stacji roboczej git repo do folderu na dysku Google.
2. Wymuś synchronizację w 100%, tymczasowo zmieniając nazwę katalogu projektu w gDrive.
3. Uzyskaj dostęp do komputera domowego za pomocą pewnego rodzaju zmian zdalnych i wypychanych.