Зелёная кнопка Code, которая бросается в глаза первой, — не та кнопка. Она отдаёт архив с исходным кодом: папки, файлы с расширениями вроде .py и .ts, сборочные конфиги и ни одной запускаемой программы внутри. Готовое приложение, если автор его вообще собрал, лежит в другом месте — в разделе Releases, в блоке Assets.
Короткий ответ на вопрос, как скачать приложение с гитхаба, такой: открываешь адрес репозитория, дописываешь к нему /releases, разворачиваешь Assets у самого верхнего релиза и берёшь файл под свою систему. Windows — .exe или .msi, macOS — .dmg, Linux — .AppImage или .deb, Android — .apk. Аккаунт для этого не нужен, платить тоже не надо.
Дальше начинается то, из-за чего этот текст длиннее трёх строк: файлов в одном релизе бывает полтора десятка, половина из них не для твоего устройства, а проверять, что именно ты скачал и кто это собрал, площадка за тебя не станет.
Про деньги сразу, чтобы потом не отвлекаться: скачивание бесплатное, а платное на GitHub тоже есть — Copilot, командные тарифы, донаты авторам через Sponsors. Российской картой это не оплатить, и такую оплату удобно сделать через SUB.SUP: пишешь в Telegram или ВКонтакте, там подскажут и оформят.
Где лежит сама программа, а не её исходники
Релиз на GitHub — это привязанный к git-тегу срез проекта, который автор упаковал и выложил, по формулировке справки, «для широкой аудитории, чтобы скачивали и пользовались». В этом определении важно каждое слово: релиз собирает и публикует человек руками. Захотел — собрал. Не захотел — в репозитории будет только код.
Попасть в нужный раздел можно тремя способами. На главной странице репозитория справа есть колонка Releases с пометкой Latest у свежей версии. Можно дописать /releases к адресу. А можно сразу /releases/latest — это постоянная ссылка на актуальный релиз, её удобно сохранить в закладки, чтобы каждый раз не искать заново. Есть и совсем прямой формат: /releases/latest/download/имя-файла скачивает конкретный ассет последней версии, минуя страницу.
Внутри релиза интересен блок Assets — он часто свёрнут, и его нужно раскрыть треугольником. Вот эти файлы автор загрузил сам: установщики, архивы, apk. А под ними GitHub всегда дорисовывает две строки — Source code (zip) и Source code (tar.gz). Их площадка генерирует автоматически из содержимого репозитория на момент создания тега. Это исходники. Не программа.
Лимиты у площадки щедрые: до тысячи файлов на один релиз, каждый — до 2 ГиБ, при этом ни на общий вес релиза, ни на трафик ограничений нет вовсе. Поэтому в Assets спокойно уживаются сборки под шесть платформ разом.
И последнее по этому блоку: публиковать релизы может только тот, у кого есть право записи в репозиторий. А читать и скачивать — любой, у кого есть доступ на чтение. Для публичного проекта это буквально любой человек с браузером.
Assets, Source code и pre-release: что из этого качать
Имена файлов выглядят как шифр, но читаются легко: в них зашиты система, разрядность и способ установки.
MyApp-2.4.1-win-x64-setup.exe — установщик для 64-битной Windows: запустил, программа прописалась в систему, появился ярлык. MyApp-2.4.1-win-x64-portable.zip — та же программа, но распаковал в любую папку и запустил, ничего в реестр не лезет. Для macOS ищи .dmg и смотри на соседнее слово: arm64 — для маков на M-процессорах, x64 — для старых интеловских. У Linux свой зоопарк: .AppImage работает почти везде без установки, .deb ставится в Ubuntu и Debian, .rpm — в Fedora.
Рядом с бинарниками часто лежат неприметные файлы вроде checksums.txt, SHA256SUMS или что-нибудь с расширением .sig. Это не служебный мусор: по ним проверяют, что скачанное не побилось по дороге и не подменилось. Отдельный блок про это будет ниже.
Пометка Pre-release значит, что автор сам считает сборку сырой: он выложил её, чтобы её попробовали смелые, а не чтобы на ней работали. Latest — наоборот, стабильная версия, на которую площадка ведёт по короткой ссылке. Если верхний релиз помечен как pre-release, стабильный лежит следующим в списке.
Ещё деталь, которую мало кто замечает: рядом с каждым ассетом GitHub показывает размер и счётчик скачиваний. Когда у одного файла двадцать загрузок, а у соседнего в том же релизе — двадцать тысяч, ты почти наверняка смотришь не на тот файл. Толпа тут работает как подсказка: подавляющее большинство людей качает сборку под самую массовую систему, и она же обычно самая обкатанная.
Какой APK из четырёх?
Классическая ситуация: в релизе четыре апк-файла, а нужен один. Разница в архитектуре процессора.
arm64-v8a — это все более-менее современные телефоны, примерно с 2018 года и новее. Бери его, если не знаешь ничего про своё устройство, но оно куплено в последние годы. armeabi-v7a — старые и совсем бюджетные аппараты. x86_64 — эмуляторы на компьютере и редкие устройства вроде некоторых хромбуков. Universal — сборка со всеми вариантами сразу: весит в полтора-два раза больше, зато встанет куда угодно.
Если гадать не хочется, посмотри в настройках телефона раздел «О телефоне» — там указана модель, а дальше архитектура ищется поиском за минуту. Ошибка не смертельна: неподходящий апк просто не установится или вылетит при первом запуске, кирпича из телефона не будет.
Как скачать приложение с гитхаба на телефон и не поймать вредонос при установке APK
Скачать приложение с гитхаба прямо на телефон можно без компьютера и без официального клиента GitHub: страница релизов нормально открывается в мобильном браузере, а ассеты качаются как обычные файлы.
Дальше самое интересное. Тапнув по скачанному апк, ты упрёшься в системный запрет: Android не даёт ставить приложения из произвольных источников, пока ты явно не разрешишь это конкретной программе — браузеру, мессенджеру или файловому менеджеру. Разрешение выдаётся не «системе вообще», а именно тому приложению, из которого идёт установка, и это правильно устроено. У меня на этом моменте каждый раз уходит лишняя минута: в разных оболочках тумблер спрятан по-своему. После установки разрешение лучше снять — оно больше не нужно.
Дальше в дело вступает Play Protect. Он, по описанию Google, проверяет устройство «на потенциально опасные приложения из других источников», а найдя такое, может прислать уведомление, отключить приложение до удаления или снести его сам. Отдельно в справке сказано, что он «может не дать установить неподтверждённое приложение». Предупреждение при установке апк с гитхаба — обычное дело и само по себе не приговор автору: система просто не знает этот файл. А вот если предупреждение конкретное, с формулировкой про вредоносное поведение, дальше лучше не идти.
И техническая мелочь, о которую спотыкаются все. Android намертво связывает установленное приложение с сертификатом, которым оно подписано: менеджер пакетов проверяет, что апк подписан вложенным в него сертификатом, и любое изменение файла подпись ломает — начиная со второй схемы подписи проверяется весь файл целиком, как один кусок данных. На практике это значит, что сборку с гитхаба нельзя поставить поверх той же программы, установленной из Play: ключи разные, система откажет. Придётся сносить старую версию вместе с её данными, так что сначала выгрузи то, что жалко потерять.
Релизов в репозитории нет — что тогда
Бывает, что вкладка Releases пустая, а собранная версия нужна. Первое место, куда стоит заглянуть, — вкладка Actions: там лежат автоматические сборки, которые запускаются на каждый коммит. Открываешь последний успешный запуск, внизу страницы будет блок Artifacts.
Две оговорки. Скачивать артефакты может только тот, кто вошёл в GitHub и имеет доступ на чтение репозитория, — анонимно не выйдет. И хранятся они по умолчанию 90 дней, а потом исчезают.
Второй момент важнее технического: артефакт — это сборка для разработчика, а не для тебя. Автор её никому не обещал, changelog к ней не писал и за её работоспособность не отвечает.
Чем рискуешь, скачивая приложение с гитхаба
Тут придётся сказать неприятное. GitHub — это хостинг кода, а не магазин приложений с модерацией. Никто не открывает твой .exe перед скачиванием и не гоняет его в песочнице.
Больше того, в правилах площадки прямым текстом написано: GitHub «разрешает контент двойного назначения и поддерживает публикацию материалов, используемых для исследования уязвимостей, вредоносного ПО или эксплойтов, поскольку публикация и распространение такого контента имеет образовательную ценность». Запрещено другое — использовать площадку для реальных атак: рассылать вредоносные исполняемые файлы, держать управляющие серверы. То есть код, который антивирус справедливо назовёт опасным, лежит на GitHub на законных основаниях. Это нормально для исследовательской платформы и совершенно ненормально, если ты воспринимаешь её как витрину проверенных программ.
Отсюда три ловушки, в которые попадают чаще всего.
Первая — репозиторий-двойник. Имя отличается одной буквой, описание скопировано, звёзды есть. Звёзды, кстати, не рецензия: их несложно получить искусственно, а вот многолетнюю историю коммитов и обсуждений подделать тяжело.
Вторая — файл не из релиза. К любому обсуждению на GitHub можно приложить архив: справка разрешает zip, gz и tgz и ставит потолок в 25 МБ на «все остальные файлы». Ссылка на такое вложение выдаётся самой площадкой и выглядит абсолютно «гитхабовской», хотя приложил файл посторонний человек в комментарии, а не автор проекта в релизе. Правило простое: качаем из Assets, а не из переписки.
Третья — README, который ведёт скачивать на сторонний сайт. Иногда это честное зеркало, иногда — способ увести туда, где никаких проверок уже нет.
Проверка перед запуском: хеш-сумма, подпись, attestation
Если в релизе есть checksums.txt или SHA256SUMS, потратить минуту стоит. Считаешь хеш скачанного файла и сравниваешь строку с той, что в файле сумм. В Windows это `certutil -hashfile имя_файла SHA256`, в macOS `shasum -a 256 имя_файла`, в Linux `sha256sum имя_файла`.
Что это доказывает: файл дошёл целым и совпадает с тем, что автор выложил. Чего не доказывает: что автору стоит доверять. Хеш проверяет дорогу, а не источник.
С источником работает штука посерьёзнее — artifact attestations. Смысл в том, чтобы «зафиксировать, где и как именно была собрана программа»: сборка на серверах GitHub оставляет криптографическую справку о том, из какого репозитория, каким процессом и когда она получена. Проверяется одной командой через официальную консольную утилиту gh:
Работает не везде: на бесплатном, Pro и Team-тарифах — только для публичных репозиториев, приватные и внутренние покрываются на Enterprise Cloud. И, конечно, справка появляется только у тех проектов, где авторы её настроили. Но если она есть — это самый сильный аргумент в пользу того, что перед тобой оригинальная сборка, а не чья-то подделка.
Три минуты на осмотр репозитория до того, как нажмёшь на зелёную кнопку
Дата последнего коммита, число контрибьюторов, живые обсуждения в Issues с ответами автора, наличие лицензии. Ни один из пунктов сам по себе ничего не гарантирует, но проект, у которого пусто во всех четырёх, на рабочий ноутбук ставить не надо.
Обновления сами не прилетят
Программа, поставленная руками, о новых версиях не узнает: механизма обновлений у скачанного апк или exe-шника просто нет, если автор не встроил его сам.
Самое простое — подписаться на релизы: кнопка Watch вверху репозитория, там Custom и галочка Releases. Уведомления придут на почту, и только про новые версии, а не про каждый коммит.
Для Android есть решение поизящнее — Obtainium, приложение с девизом «получай обновления приложений прямо из первоисточника». Оно следит за страницами релизов и само предлагает поставить свежую версию, а источников понимает много: GitHub, GitLab, Codeberg, F-Droid, SourceHut, APKPure, RuStore и просто прямые ссылки на апк. Само оно, что логично, раздаётся через релизы на GitHub.
Второй маршрут — F-Droid. Там приложения собирают из исходников на своей стороне и подписывают собственным ключом, а разработчик может подписывать сам, если его сборка воспроизводима — то есть «любой, у кого есть тот же исходный код, получит ровно тот же бинарник». Медленнее, зато между тобой и файлом появляется хоть какой-то посредник, который смотрит на код.
Скачивание бесплатное — а платит на гитхабе кто и за что
Скачать приложение с гитхаба нельзя за деньги — там нет такой кнопки в принципе. Деньги на площадке крутятся вокруг другого.
Личный тариф Free стоит ноль. Team на странице цен указан как 4 доллара за пользователя в месяц, Enterprise — от 21 доллара, но у обеих цифр стоит приписка «за первые 12 месяцев», так что это условия первого года, а не вечный прайс: перед оплатой сверься с официальной страницей тарифов. Отдельно тарифицируются Git LFS (5 долларов в месяц за 50 ГБ хранилища и столько же трафика) и Codespaces — от 0,18 доллара за час работы машины. Если упрётесь в оплату, посмотрите пошаговую инструкцию: «Как оформить подписку GitHub из России в 2026 году».
Самая ходовая платная история — Copilot. Бесплатный уровень даёт 2000 автодополнений в месяц, Pro стоит 10 долларов в месяц, Pro+ — 39, Max — 100, а командные места считаются по 19 и 39 долларов. Плюс Sponsors: у половины полезных проектов в README висит кнопка доната автору, и это, по-моему, самый честный способ сказать спасибо за бесплатную программу. Всё перечисленное оплачивается зарубежной картой, чего у большинства читателей просто нет; если нужен любой из этих платежей, проще не воевать с системой, а написать в SUB.SUP — Telegram или ВКонтакте, там разберутся с оформлением.
И вот тут стоит остановиться на секунду. Бесплатно — не значит «без обязательств». В магазине приложений между тобой и разработчиком стоит привратник, который что-то проверил и за что-то отвечает. На GitHub привратника нет: есть автор, есть его код, есть ты и твоё решение нажать на кнопку. Три минуты на хеш и историю коммитов — это и есть цена бесплатного.
Частые вопросы про скачивание приложений с гитхаба
### Нужен ли аккаунт GitHub, чтобы скачать файл из релиза?
Нет. Просматривать и сравнивать релизы может любой, у кого есть доступ на чтение, а у публичного репозитория он есть у всех. Регистрация понадобится в одном случае — если ты полез за артефактами сборки во вкладку Actions: там нужен вход в аккаунт.
### Почему Windows блокирует запуск, а антивирус ругается на файл из релиза?
Чаще всего потому, что у сборки нет сертификата разработчика — он платный, и авторы бесплатных проектов его обычно не покупают. SmartScreen смотрит на репутацию файла, а у свежего релиза её нет по определению. Это не индульгенция: сверь хеш и посмотри, из того ли репозитория файл. Но само по себе такое предупреждение ещё ничего не доказывает.
### Можно ли скачать приложение с гитхаба прямо на телефоне, без компьютера?
Да, страница релиза открывается в мобильном браузере и файл качается как любой другой. Единственное неудобство — блок Assets на узком экране приходится разворачивать вручную, и легко промахнуться по нужной строке. Проверь имя файла после скачивания, а не до.
### Что означает пометка pre-release и стоит ли ставить такую сборку?
Так автор помечает версию, которую сам считает недоделанной: свежие функции есть, стабильности нет. Ставить имеет смысл, когда очень нужна конкретная новая возможность и ты готов откатиться на предыдущий релиз. Для рабочего инструмента бери версию с меткой Latest.
### Как отличить настоящий репозиторий от копии-двойника?
Заходи по ссылке с официального сайта проекта или из его документации, а не из поиска. Сверь автора, дату первого коммита и число форков: у копии история короткая, обсуждений нет, а релиз обычно один-единственный и свежий. И помни, что вложение из комментария к обсуждению — это не релиз, даже если ссылка ведёт на домен GitHub.
Комментарии
Войдите, чтобы написать комментарий