Локальный адрес виден только на твоём компьютере. Опубликуем подготовленную игру на GitHub Pages и получим HTTPS-ссылку, которую можно открыть без твоего редактора и локального сервера.

Что потребуется

Возьми свою папку release из подготовки выпуска. Для этого способа нужны доступ к github.com, аккаунт GitHub с подтверждённой почтой и права управлять собственным репозиторием. Репозиторий — папка файлов с историей Git на сервере. Git из урока 11 и аккаунт GitHub — разные вещи.

Выбираем публичный репозиторий на GitHub Free. Такой вариант поддерживает Pages без покупки домена. HTML, CSS и JS выполняются в браузере; Pages не запускает наш сервер, базу данных или код Node.js. Для этой небольшой игры они не нужны. Источник: что такое GitHub Pages.

Публичными будут и сайт, и файлы репозитория. Загружай только подготовленный выпуск. Не добавляй рабочие записи о людях, секреты и весь учебный ZIP. Если доступ к сервису или возможность сделать код публичным не подходят, этот способ пока не даст внешний результат; локальный запуск сам по себе публикацией не становится.

По ограничениям GitHub Pages, проверенным 23 сентября 2026 года, размер сайта не должен превышать 1 ГБ, мягкий лимит трафика — 100 ГБ в месяц, сборок из ветки — 10 в час. Для небольшой учебной игры этого обычно достаточно; это не обещание неограниченного сервиса. Pages не предназначен для интернет-магазина или коммерческого SaaS. Перед другим использованием проверь текущие условия по ссылке.

Подготовь файлы публикации

В комплекте урока start совпадает с release предыдущего примера, а final добавляет пустой файл .nojekyll. Игровое правило не меняется. Свою папку пока держи отдельно от примера. Файл .nojekyll сообщает публикации, что наш готовый статический сайт не нужно обрабатывать как Jekyll-проект. Его можно создать прямо в репозитории на следующем этапе.

У index.html должно быть именно такое имя строчными буквами. Нужна входная страница в корне публикуемой папки, а не release/index.html при публикации корня родительского каталога. Условия описаны в инструкции создания Pages-сайта.

Создай репозиторий и загрузи содержимое

Войди в свой аккаунт GitHub. В меню «+» выбери New repository. В качестве имени возьми короткое латинское имя, например my-game. Это пример имени, а не уже созданный адрес.
Выбери Public и включи Add README, чтобы появилась первая ветка. Создай репозиторий. В списке файлов проверь имя ветки: дальше используем main; если у тебя другое, подставляй его в настройки.
На вкладке Code открой Add file → Upload files. Перетащи содержимое своей release-папки: index.html должен оказаться рядом с README, а не внутри дополнительной release. Подпапки assets/styles сохраняй, если они есть.
Перед сохранением просмотри список. В сообщении коммита напиши, например, «Publish game version 1.0». В своём новом репозитории выбери сохранение непосредственно в main и подтверди коммит. Если правила репозитория требуют pull request, доведи его до слияния в выбранную ветку: Pages публикует её состояние.
Вернись в корень Code. Через Add file → Create new file введи имя .nojekyll, оставь файл пустым и сохрани коммит в ту же ветку. Если файл уже есть после загрузки, второй не нужен.

Через веб-интерфейс можно загружать до 100 файлов за раз, каждый — до 25 МиБ. Наш пример намного меньше. Смысл кнопок загрузки и коммита описан в GitHub Docs: добавление файла. В этом уроке используем загрузку через браузер; команды push и настройка авторизации не нужны.

Укажи, какую ветку публиковать

Открой Settings своего репозитория, затем Pages в боковом меню.
В Build and deployment → Source выбери Deploy from a branch.
В Branch выбери main, рядом — /(root). Нажми Save.
Открой вкладку Actions. Дождись успешного запуска публикации Pages. Если он завершился ошибкой, открой его журнал; повторная загрузка тех же файлов не объяснит причину.
Вернись в Settings → Pages и открой Visit site. Копируй адрес оттуда, а не адрес репозитория.

Даже публикация из ветки выполняется служебным workflow GitHub Actions; свой YAML для нашего случая писать не нужно. По документации изменение может появиться в течение десяти минут. Источник настроек: публикация из ветки и папки.

Папка проекта входит в адрес

У сайта отдельного репозитория адрес выглядит так: Подставляются твои имя аккаунта и имя репозитория. Адрес github.com/... показывает исходники; github.io/... — опубликованную игру.

https://YOUR-NAME.github.io/my-game/

./game.js  → https://YOUR-NAME.github.io/my-game/game.js
/game.js   → https://YOUR-NAME.github.io/game.js

Во втором запросе пропала папка my-game. Поэтому знакомые ./style.css, ./game.js и ./rules.js важны и здесь. При относительных путях имя аккаунта не нужно указывать в коде игры. Как браузер находит файл по относительному пути импорта, объясняет MDN.

Проверь ссылку как внешний игрок

Останови локальный сервер. Открой HTTPS-ссылку из Visit site в другом браузере, где ты не входил в GitHub. Если проверяешь на телефоне, открывай именно эту ссылку, а не localhost. Пройди свежий старт, победу, поражение и новую попытку. Проверь клавиатуру или пальцы согласно заявленному управлению; прочти цель без пояснений автора.

В Network найди HTML, CSS, game.js и импортируемые модули. Успешный HTML ещё не доказывает, что остальные файлы загрузились. Запиши адрес выпуска, коммит, браузер/устройство и результат в templates/publication-check.md вне публичной папки. Для внешних ресурсов нужны HTTPS-адреса: правила смешанного содержимого описаны в документации HTTPS.

Что видно	Куда смотреть
Сам сайт возвращает 404	Успешна ли публикация; main/(root); есть ли index.html именно в корне и строчными буквами
HTML есть, кнопки не работают	Network/Console: game.js, rules.js, type="module", расширение и регистр
Пропало оформление	href, сохранённая подпапка styles, начальный / вместо ./
После обновления старая версия	Коммит попал в нужную ветку; последний workflow успешен; после этого перезагрузка без кэша
В адресе остался localhost	Это локальная проверка; скопируй внешний адрес из Pages

Регистр index.html и уровень папки отдельно разбираются в руководстве по ошибке 404. Не меняй одновременно несколько настроек: сохрани конкретный ошибочный запрос и проверяй одну причину.

Опубликуй свою игру и обнови её

Выполни весь путь со своей release-папкой. Затем исправь одно найденное затруднение инструкции или одну подтверждённую ошибку. Сначала проверь новую локальную копию и запиши Git-коммит. Загрузи изменённые файлы в тот же репозиторий и ту же ветку; не создавай второй сайт ради новой версии. Если переименовал файл, убери старый из публикуемого дерева через GitHub и проверь ссылки на новое имя.

Дождись нового успешного запуска Actions и повтори внешний сценарий по прежней ссылке. Сравни наблюдаемое изменение, а не только номер коммита. Сохрани обе записи проверки: первая публикация и обновление.

Подсказка 1: потренируйся на пути /my-game/

До публикации положи копию игры в подкаталог my-game внутри пустой папки проверки и запусти HTTP-сервер из её родителя. Открой /my-game/. Это обнаружит начальный / в запросах, но не проверит настройки GitHub и не создаст внешний адрес.

Подсказка 2: сломанный путь в комплекте

В broken-path подключение game.js намеренно начинается с /. При открытии вложенного каталога оно запрашивает файл корня сервера. Исправь src на ./game.js, перезагрузи и проверь, что запрос остался внутри каталога игры.

Сверка после попытки

В final лежат файлы для публикации демонстрационного проекта, включая пустой .nojekyll. Это пример дерева, а не готовая внешняя ссылка и не результат самостоятельной игры. В templates есть форма проверки; заполняй её фактическими результатами своего размещения.

Когда публикация готова

У тебя есть внешний HTTPS-адрес, открывающий именно твою игру без запущенного локального сервера. В другом браузере загружаются все ресурсы, управление работает на заявленном устройстве, а повторная публикация меняет ту же страницу. Проверь саму внешнюю ссылку: наличие архива, коммита или успешного локального запуска ещё не означает, что сайт опубликован.

Публикуем браузерную игру через GitHub Pages