VPN для GitHub

Четыре разных канала под одним именем

Веб-интерфейс — обычный сайт: страницы по несколько сотен килобайт, много мелких запросов, никаких особых требований к каналу. Он открывается почти всегда, и именно поэтому создаёт ложное впечатление, что с доступом всё в порядке.

git по HTTPS работает поверх 443-го порта и внешне похож на обращение к сайту, но ведёт себя иначе: это одна длинная передача, которая может идти минутами. git по SSH использует 22-й порт и отдельный протокол; в сетях, где нестандартные порты режутся, он падает при живом HTTPS. На такой случай GitHub держит альтернативный вход по SSH через 443-й порт.

Четвёртый канал — реестры пакетов: ghcr.io для образов, отдельные хосты для пакетов npm и Python. Они физически раздаются с других узлов, и их доступность вообще не связана с доступностью репозитория. Отсюда типичная картина: страница проекта открыта, а сборка падает на скачивании зависимостей.

Большие клоны, LFS и что делать при обрывах

Обычный клон передаёт всю историю проекта одним потоком. Если соединение оборвалось на 80%, git не умеет продолжить с этого места — операция начинается заново. Отсюда и знаменитое «встал на 40%»: канал не мёртвый, он просто рвётся раз в несколько минут, и вы никогда не доходите до конца.

Есть штатные приёмы, которые снижают риск. Поверхностный клон с ограничением глубины истории забирает только последние коммиты и сокращает объём в разы. Клон одной ветки вместо всех тоже помогает. Увеличение буфера передачи в настройках git — параметр http.postBuffer — иногда снимает падения на больших push.

Отдельная история — крупные файлы через LFS. Они качаются не вместе с историей, а отдельными запросами к хранилищу, и на неровном канале сыпятся уже после того, как основной клон успешно прошёл. В логе это видно как ошибка загрузки конкретного объекта; повторный запуск команды дотягивает недостающие файлы, не начиная всё заново.

Actions, Codespaces и корпоративный прокси

Сценарии GitHub Actions выполняются на серверах платформы, и ваш канал на скорость их работы не влияет. Влияет он на другое: на просмотр журналов в реальном времени и на скачивание артефактов сборки, которые нередко весят сотни мегабайт. Ощущение «Actions тормозят» чаще всего означает именно медленную выгрузку журнала.

Codespaces — среда разработки в облаке, и это уже интерактивный канал, чувствительный к задержке. Работать в веб-редакторе при 250 мс до сервера физически неприятно: буквы появляются с опозданием после нажатия. Здесь имеет смысл сознательно выбрать ближнюю локацию, даже если она чуть медленнее по полосе.

В корпоративной сети между вами и GitHub нередко стоит прокси компании со своим сертификатом. git о нём не знает и выдаёт ошибку проверки сертификата. Правильное решение — прописать адрес прокси и корневой сертификат компании в настройках git, а не отключать проверку сертификатов: последнее лишает вас защиты от подмены и обычно нарушает внутренние правила безопасности.

Границы, которые мы не переходим

Если доступ к GitHub закрыт правилами вашего работодателя, это его осознанное решение по управлению рисками: утечка исходного кода — реальная проблема, а не выдумка службы безопасности. Мы не подсказываем способы обойти такие правила и не считаем это полезным советом.

Разница практическая, а не риторическая. Когда сотрудник обходит корпоративный контур, он лишает компанию видимости и одновременно подставляет себя: такие вещи обнаруживаются при первом же аудите. Запрос в ИТ-отдел с описанием рабочей задачи закрывает вопрос легально и обычно быстрее, чем кажется.

То же касается ограничений самой платформы, привязанных к региону аккаунта. Мы не советуем указывать недостоверные сведения в профиле или пытаться выглядеть пользователем другой юрисдикции. Наша область — транспорт: маршрут без потерь до серверов сервиса, чтобы клон доходил до конца, а push не падал по таймауту.