Спроба чогось подібного git clone git://github.com/ry/node.gitне вийде, це призводить до:

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)

Однак клонування через HTTP працює чудово. Поки я зібрався, що проблема з протоколом, але я намагаюся встановити cloud9, який вимагає команди

git submodule update --init --recursive

який намагається використовувати протокол git: // і не працює. Чи є спосіб змінити, як буде працювати ця команда чи щось таке?

Якщо це проблема з тим, що ваш брандмауер блокує порт git: протокол (9418), тоді вам слід зробити більш стійкі зміни, щоб вам не потрібно було пам'ятати, щоб видавати команди, запропоновані іншими повідомленнями для кожного git repo.

Наведене нижче рішення також просто працює для підмодулів, які також можуть використовувати протокол git:

Оскільки повідомлення git насправді не вказує відразу на порт блокування брандмауера 9418, спробуємо діагностувати це як фактичну проблему.

Діагностування проблеми

Довідкова інформація: https://superuser.com/q/621870/203918 та https://unix.stackexchange.com/q/11756/57414

Існує кілька інструментів, якими ми можемо визначити, чи є брандмауер причиною нашої проблеми - використовувати те, що встановлено у вашій системі.

# 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

Гаразд, тому ми визначили, що наш порт git блокується брандмауером, що ми можемо з цим зробити? Читайте далі :)

Переписування основної URL-адреси

Git надає спосіб переписати URL-адреси за допомогою git config. Просто задайте таку команду:

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

Тепер, ніби за допомогою магії, всі команди git будуть виконувати заміну git://наhttps://

Які зміни внесла ця команда?

Погляньте на вашу глобальну конфігурацію, використовуючи:

git config --list

У висновку ви побачите наступний рядок:

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

Ви можете побачити, як це виглядає у файлі, заглянувши ~/.gitconfigтуди, де тепер слід побачити, що два наступні рядки були додані:

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

Хочете більше контролю?

Просто використовуйте більш повну / конкретну URL-адресу для заміни. Наприклад, щоб лише URL-адреси GitHub використовували https: // замість git: //, ви можете використовувати щось на зразок:

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

Ви можете запустити цю команду кілька разів, використовуючи різні замінники. Однак, якщо URL-адреса відповідає декільком замінам, найдовша відповідність "виграє". Буде здійснена лише одна заміна за URL-адресою.

Системні зміни для систематичних систем

Якщо ви Linux Sysadmin і не хочете, щоб ваші користувачі переживали вищевказані болі, ви можете швидко змінити конфігурацію git у всій системі.

Просто відредагуйте або додайте наступний вміст /etc/gitconfigі переконайтеся, що ваші користувачі не повинні турбуватися ні про що з перерахованого вище:

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

Github також надає доступ http (s), що набагато рідше буде заблоковано вашою компанією. Щоб сказати підмодулю використовувати це, ви можете зробити це:

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

Це насправді саме тому init та update є окремими командами - ви можете викликати, налаштувати місця, а потім оновити. update --initце лише ярлик, коли вам не потрібно налаштовувати будь-які URL-адреси.

Для всіх, хто трапляється через це, ви, звичайно, також можете використовувати ssh URL (якщо ваша компанія блокує git: //, але не ssh), але в цьому випадку ОП, мабуть, не має доступу SSH до віддаленого репо.

Інший варіант, який не передбачає торкання git config, - це зміни параметрів ssh, щоб використовувати порт 443 замість звичайного 22 порту.

Довідка: Використання SSH через порт HTTPS

З цієї статті:

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

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

Після цього мені вдалося вдало натиснути на Github. В домашніх умовах ви можете змінити назад ssh config так, як це було, якщо хочете.

Я також певний час мав те саме питання. Потім я спробував змінити конфігурацію git за допомогою запропонованої команди:

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

який, на жаль, не зробив для мене хитрості . У мене ще були ті ж проблеми!

Що насправді вирішило нарешті мою проблему, я знову скинув віддалений URL свого сховища за допомогою наступної команди:

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

що раніше було таким:

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

Після встановлення віддаленого URL-адреса https://замість git@git.comпроблеми для мене було вирішено.

Розширюючи відповідь Натана вище, ви також можете спробувати протокол ssh, якщо ваш корпоративний брандмауер заважає https. У моєму випадку брандмауер блокував протокол git, повторно видавав ssl сертифікати для https, і це порушило функцію для мене, навіть при вимкненому режимі строгої ssl. Ви можете зробити подібний перезапис URL-адреси для ssh та створити ключ / пару ssh, як описано в github .

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

Вам також доведеться ввімкнути ssh-агент для вашої установки git.

це тому, що адреса GIT для сервера вузлів змінилася, вам зараз потрібно ввести:

git clone https://github.com/joyent/node

Щасти

Вступ

Я додам сюди власний підхід ( який не потрібен, якщо у вас є загальнодоступне сховище git, яке підтримує https ).

Я працюю в компанії, де сховище git доступне лише зсередини компанії. Але я теж працюю вдома.

Як мені перейти до сховища компанії з дому?

Я створив сховище з папкою на своєму диску Google. За винятком git та https, ви можете включати сховища як шляхи.

Отже, замість того, щоб підштовхувати до початку, я натискаю на "gDrive". Це призводить до того, що папка синхронізується з моєї домашньої робочої станції на Google Drive, а потім мій робочий комп'ютер витягує зміни. Крім того, оскільки іноді файли в каталозі ".git" не синхронізуються, я тимчасово перейменовую папку з, наприклад, "trunk" на "trunk2". Це змушує домашні та робочі комп’ютери 100% синхронізуватися з Google Drive.

Потім я входжу на свій робочий комп'ютер через пульт дистанційного контролю (checkpoint-vpn) (або teamviewer) і натискаю свої оновлення до сховища роботи git.

Крім того, цей процес буде працювати навпаки, щоб перейти до сховища git за межами компанії, що блокується.

1. Натисніть з робочої станції git repo на папку в Google Drive.
2. Примушуйте 100% синхронізувати, тимчасово перейменувавши каталог проектів у gDrive.
3. Доступ до домашнього комп'ютера через якісь віддалені та натискання змін.