Błędy Git / Bower: kod zakończenia # 128 i nieudane połączenie

Używam Bower do zainstalowania kilku bibliotek. W celach demonstracyjnych instaluję bootstrap. Niezależnie od paczki otrzymuję następujące błędy:

C:\Scott>bower install bootstrap
bower not-cached    git://github.com/twbs/bootstrap.git#*
bower resolve       git://github.com/twbs/bootstrap.git#*
bower ECMDERR       Failed to execute "git ls-remote --tags --heads git://github
.com/twbs/bootstrap.git", exit code of #128

Additional error details:
fatal: unable to access 'https://github.com/twbs/bootstrap.git/': Failed connect
to github.com:443; No error    

Próbowałem użyć następującego rozwiązania, aby usunąć pierwszy błąd - który znalazłem podczas tego wyszukiwania :

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

Jednak to nie działa, ani żadne z innych rozwiązań znalezionych na tej stronie. Szukając rozwiązania dla drugiego błędu, wydaje się, że ustawienie nazwy użytkownika / pwd dla serwera proxy rozwiąże problem, jeśli jesteś w sieci firmowej / za zaporą. Jednak nie używam serwera proxy, ponieważ jestem na moim domowym komputerze / sieci (Windows 7 x64).

Dzięki!

EDYCJA: okno poleceń z błędami:

Wiem, że to nie jest „naprawianie” problemu, ale możesz użyć

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

powiedzieć gitowi, aby używał HTTPS zamiast GIT, co sprawiło, że zainstalowałem zależności npm.

Zamiast tego uruchomić to polecenie:

 git ls-remote --tags --heads git://github.com/twbs/bootstrap.git

powinieneś uruchomić to polecenie:

 git ls-remote --tags --heads git@github.com:twbs/bootstrap.git

lub

 git ls-remote --tags --heads https://github.com/twbs/bootstrap.git

lub możesz uruchomić, git ls-remote --tags --heads git://github.com/twbs/bootstrap.gitale musisz sprawić, by git zawsze używał https w ten sposób:

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

Źródła: https://github.com/bower/bower/issues/50

Natknąłem się na to w mojej sieci firmowej.

Wydawało się to dziwne, ponieważ zawsze używałem ssh do łączenia się z git i nigdy nie miałem problemu.

Próbowałem https i nie działało, więc dodałem ustawienia proxy do konfiguracji gita i wszystko było dobrze

git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
git config --global https.proxy https://proxyuser:proxypwd@proxy.server.com:8080

I upewniając się, że zadziałało

git config --list

Port 22 był blokowany na moim komputerze. Kiedy znalazłem to, co go blokowało i otworzyłem port, mogłem uruchomić instalację cmd bower bez żadnych problemów.

Wygląda na to, że azsl1326 nie użył bower (git) przez port 9418 (git: //), a następnie powiedział gitowi, aby zamiast tego używał portu 22 (https: //). To wciąż nie działało, ale potem otwarcie portu 22 dało pożądany rezultat.

Najbardziej bezpośrednim rozwiązaniem jest otwarcie portu 9418. Jest to port używany przez protokół git: //.

Przejdź do folderu aplikacji i uruchom to polecenie

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

"

To powinno rozwiązać problem

Być może musisz wygenerować klucz ssh, aby uwierzytelnionym za pomocą github.

Czy jesteś za firewallem?

Git nie pobiera konfiguracji proxy, gdy jest wywoływany, więc jawnie ustaw zmienne środowiskowe, np .:

export HTTP_PROXY=http://username:password@proxyserver:port/
export HTTPS_PROXY=http://username:password@proxyserver:port/

Jeśli Twój korporacyjny serwer proxy nie wymaga uwierzytelniania, po prostu pomiń username:password@ bit w adresach URL.

U mnie zadziałało!

Jeśli twój kraj blokuje github, np. Chiny kontynentalne, możesz zbudować proxy, np. Użyć goagent & gae, a następnie ustawić adres proxy dla git, np.

git config --global http.proxy 127.0.0.1:8087

Ten błąd jest związany ze złą konfiguracją zapory. Zauważysz, że bower próbuje skontaktować się z git za pośrednictwem git://protokołu, a nie http://. Musisz otworzyć port 9418. Dodaj te dwie linie do konfiguracji iptables:

iptables -t filter -A INPUT -p tcp --dport 9418 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 9418 -j ACCEPT

To powinno załatwić sprawę.

Najpierw sprawdź, czy wiersz polecenia programu Visual Studio rozpoznaje polecenie git: Narzędzia> Wiersz polecenia

C: \ .... \> git

jeśli to polecenie nie zostanie rozpoznane, należy dodać folder git do zmiennych środowiskowych

https://stackoverflow.com/a/26620861/3449657

To jest to, czego mi brakowało i załatwiło mi sprawę.

Mam nadzieję, że to pomoże.

Dodaję tutaj moją odpowiedź, ponieważ jest to jedno z najbliższych pytań, które pasują do mojej sytuacji. Próbowałem zainstalować select2 zamiast ładowania początkowego, ale wynik był taki sam.

bower install select2zgłosił, że git nie może zlokalizować katalogu. Używany

git config --global url. „https: //” .insteadOf git: //

config fix, ale to spowodowało (parafrazowany) błąd

Nie mogę używać protokołu HTTPS

Mój problem został rozwiązany niezadowalająco, ponieważ dotyczy magii.

Próbowałem uruchomić to w powłoce poleceń (cmd.exe, Windows). Uruchomiłem to samo polecenie i uruchomiłem je w programie PowerShell i zadziałało. ಠ_ಠ

tl; dr: połączenie https: // i PowerShell działało dla mnie

Ten błąd wystąpił po tym, jak mój program antywirusowy poddał kwarantannie pobieranie z github.com. Z jakiegoś nieznanego powodu.

Po wyczyszczeniu tych plików (pliki exe) wszystko działało.

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

nie działa dla mnie. Więc znalazłem tę alternatywę:

Przejdź do folderu tymczasowego. (tj. jeśli używasz wtedy systemu Windows C:\Users\{username}\AppData\Roaming\bower\cache\packages). Możesz tam zobaczyć kilka plików. Otwórz każdy z nich i zobaczysz adres URL. Zmień go z git://...na https://...i zapisz wszystkie pliki.

Teraz uruchom bower install.

Sprawdź ustawienia konfiguracji git ( git config --global --edit). W moim przypadku było kilka nieaktualnych wpisów, takich jak:

[core]
gitproxy = gitproxy.cmd
["https: //"]
["https: //"]
[url "https: //"]

Popraw je i usuń, jeśli już ich nie potrzebujesz.

Twoje klucze są złe. Po prostu dodaj je do GitHub / Bitbucket / czegokolwiek, z czego korzystasz. To nic innego jak problem z uprawnieniami do kluczy.

Jednak nie używam serwera proxy, ponieważ jestem na moim domowym komputerze / sieci

Miałem ten sam problem (uzyskiwanie kodu zakończenia 128) w mojej sieci domowej i byłem całkiem pewien, że nie używam proxy. Okazało się, że Git zapisał proxy, które wprowadziłem jakiś czas temu - po rozejrzeniu się po konfiguracjach znalazłem je pod znacznikiem [http].

Jestem nowy w Git i wcale nie jestem pewien, czy te konfiguracje są zwykle łatwo dostępne - używam Tortoise Git, ponieważ naprawdę nie robię nic wymyślnego i ma GUI do rzeczy.

Mam nadzieję, że „odpowiedź” mimo wszystko pomoże.

W moim przypadku był to dostęp do folderu, w którym byłem podczas wykonywania polecenia! W systemie Windows utworzyłem folder najpierw za pomocą wiersza poleceń: mkdir "MyFolder" i wystąpił błąd. ale jeśli utworzę folder za pomocą myszy, kliknij prawym przyciskiem myszy, utwórz folder itp. Działa dobrze!

Jeśli uwierzytelniasz za pomocą Bitbucket, pojawia się błąd 128 i nieudane połączenie. ale przy uwierzytelnianiu git hub działa dobrze.

Wiem, że to stare pytanie, w każdym razie pozwól mi dodać jeszcze jedną rzecz.

Czasami (jeśli jesteś w biurze lub w sieci prywatnej) zapora serwera bramy blokuje żądania https (port 443) z terminala poleceń

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

Użyj tego, aby skonfigurować git do używania protokołu HTTP przez https w takich sytuacjach

To zadziałało dla mnie,

Skopiuj plik „libcurl.dll” do folderu instalacyjnego Git (C: \ Program Files \ Git \ bin \ libcurl.dll). Wklej go w miejscu, w którym znajduje się plik git.exe (C: \ Program Files \ Git \ libexec \ git-core).

Uruchom te 2 polecenia, aby przyznać dostęp do git za pośrednictwem systemu

eval `ssh-agent`
ssh-add ~/.ssh/id_rsa

Te polecenia zakładają, że masz klucz ssh na zdalnym serwerze git (bitbucket / github / other)

Napotkałem również ten błąd i rozwiązałem go, aktualizując git. Kiedy uruchomiłem nieudane polecenie git ls-remote, podstawowym błędem było to, że używana była stara wersja tls. Tak zaktualizowana wersja git używa późniejszej wersji tls.

https://git-scm.com/download/win

Znalazłem ten błąd na moim systemie operacyjnym Linux. i rozwiązuję ten problem 1. otwórz eksport dziennika curl GIT_CURL_VERBOSE = 1 2. sklonuj repozytorium git 3. znajdź dziennik 4. naprawiam problem przez aktualizację nss i curl (aktualizacja yum nss nss-util nspr curl)