Live-данные · обновлено 19 июля 2026 г.
GitHub: что это такое, репозитории, Pull Request и Actions
Вы написали код, но как показать его команде, собрать релиз и не потерять историю изменений? GitHub решает эти задачи, объединяя разработчиков вокруг кода. Платформа давно переросла статус «облачного хранилища для Git» и стала центром CI/CD, управления проектами и командного взаимодействия. Сегодня это главная платформа совместной разработки в мире — навык встречается в 206 московских IT-вакансиях, что составляет 2.9% от всех активных предложений.
КВКузнецов Вячеслав·Технический редактор·DevOps/SRE-техлид · опыт 10+ лет
Вакансий
206
активных в Москве
Медиана зарплаты
230 тыс. ₽
n = 62 вакансии с указанной зарплатой
Индекс спроса
76/100
#79 из 332 навыков
Доля IT-рынка
2.9%
41 профессий
Коротко о навыке
GitHub критически важен для backend, fullstack, DevOps и QA-инженеров — владение платформой считается базовым требованием. За последние годы к базовому Git-хостингу добавились Actions, Codespaces, Copilot и Packages: хранение репозиториев, pull request'ы с code review, встроенный CI/CD и управление проектами через Issues.
Что такое GitHub
Главные фишки
Pull Request'ы, GitHub Actions, Issues, GitHub Pages, Codespaces, Dependabot и огромное open source-сообщество.
Когда использовать
Для командной разработки (от 2 до 1000+ разработчиков), open source, CI/CD, хранения кода и проектов любого масштаба.
Простыми словами
Представьте Google Docs для кода. Несколько человек одновременно редактируют один документ, видят правки друг друга и могут откатить изменения. GitHub делает то же самое с программным кодом, только гораздо мощнее: добавляет системы проверки, автоматизации и обсуждения.
Как это работает
GitHub — облачный сервис для хранения Git-репозиториев с веб-интерфейсом, системой pull request'ов, встроенным CI/CD (GitHub Actions) и инструментами управления проектами (Issues, Projects, Discussions). Разработчики пушат код из локального Git-репозитория в удалённый на GitHub, а затем через PR и code review изменения попадают в основную ветку.
Чего GitHub не делает
GitHub — это не замена Git, а веб-интерфейс для него. Это не полноценная IDE (хотя есть Codespaces — облачная среда с VS Code). Это не файловое облако вроде Google Drive — каждая правка отслеживается и версионируется. Ключевое отличие от Git: Git работает локально, GitHub — социальная сеть для кода.
Понятия / Карта
Из чего состоит GitHub
Понятие Что это Что нужно уметь
Repository (репозиторий)
Папка проекта с историей версий на GitHub
Создавать, клонировать, пушить, управлять доступом
Branch (ветка)
Ответвление от основной линии разработки
Создавать, переключаться, сливать, удалять
Commit
Снимок изменений с сообщением
Писать осмысленные сообщения, подготовить коммит
Pull Request (PR)
Запрос на вливание изменений из одной ветки в другую
Открывать, ревьюить, мёржить, разрешать конфликты
Issue
Задача, баг-репорт или предложение
Создавать, назначать, маркировать, связывать с PR
GitHub Actions
Встроенная система CI/CD
Писать workflow, настраивать триггеры, кэшировать
GitHub Pages
Бесплатный хостинг статических сайтов
Настроить и опубликовать сайт из репозитория
Fork
Копия чужого репозитория под вашим аккаунтом
Форкать, синхронизировать, отправлять PR в оригинал
Protected branch
Ветка с защитой от прямого пуша и обязательными проверками
Настраивать правила, включать code review и CI
.gitignore
Файл с правилами игнорирования файлов и папок
Добавлять стандартный .gitignore для языка
Git LFS
Расширение для работы с большими файлами
Настраивать LFS, отслеживать и пушить большие файлы
GitHub Secrets
Зашифрованные переменные для конфиденциальных данных
Создавать, использовать в Actions, ограничивать доступ
Механика / Работа
Как работает GitHub в реальной задаче
Рабочая цепочка GitHub идёт от причины изменения к защищённой ветке: задача, ветка, коммит, pull request, проверка, ревью, слияние, релиз и след в истории.
Шаг Слой Смысл
Шаг 01
Завести задачу
Зафиксировать причину изменения и ожидаемый результат.
Шаг 02
Сделать ветку
Отделить работу от основной линии проекта.
Шаг 03
Подготовить коммит
Внести правку и оставить понятную историю изменения.
Шаг 04
Открыть pull request
Собрать описание, checks и контекст для ревью.
Шаг 05
Пройти review
Разобрать замечания и обновить ветку без обхода правил.
Шаг 06
Сделать merge и выпуск
Слить изменение и связать его с версией продукта.
Карьера / Роли
Кому нужен GitHub
GitHub переносится между ролями: DevOps-инженер, Бэкенд-разработчик, Python-разработчик. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Роли с GitHub за период
DevOps-инженер держит 60.7% вакансий по навыку.
Роль Упоминаний за период Медиана
Ещё 7 ролей используют GitHub
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Практика / Задачи
Частые задачи с GitHub
GitHub ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
# Задача Что делает специалист
Задача 01
Создать репозиторий и запушить первый коммит
Инициализируйте локальный репозиторий, создайте файл и отправьте его на GitHub.
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/username/repo.git
git push -u origin main
Задача 02
Открыть Pull Request
Создайте ветку, внесите изменения, отправьте ветку в удалённый репозиторий и откройте PR через интерфейс GitHub.
git checkout -b feature-branch
git add .
git commit -m "Add new feature"
git push origin feature-branch
Задача 03
Настроить GitHub Actions
Создайте файл .github/workflows/ci.yml с базовым CI-пайплайном: checkout, установка зависимостей и запуск тестов.
Задача 04
Защитить main ветку
В настройках репозитория (Settings > Branches) добавьте правило для ветки main: включите «Require pull request reviews» и...
Задача 05
Сделать fork и предложить изменения
Найдите открытый проект, нажмите Fork, склонируйте свою копию, внесите правки, отправьте PR через интерфейс GitHub.
Задача 06
Опубликовать сайт на GitHub Pages
Создайте репозиторий username.github.io, поместите туда HTML-файлы, включите GitHub Pages в настройках — сайт станет доступен по...
Практика / Ошибки
Ошибки новичков
Ошибка 01
Пуш напрямую в main без code review
Это самая частая ошибка новичков. Используйте feature-ветки и Pull Request с обязательным ревью. Включите защищённую ветку, чтобы запретить прямой пуш.
Ошибка 02
Слишком большие Pull Request'ы
PR на 500+ строк сложно ревьюить, ошибки легко пропустить. Делите задачу на логические коммиты и отправляйте частые PR по одной фиче.
Ошибка 03
Игнорирование .gitignore
Забыв про .gitignore, вы рискуете закоммитить node_modules, .env, собранные артефакты и даже пароли. Всегда добавляйте .gitignore в первый же коммит.
Ошибка 04
Плохие commit-сообщения
Сообщения вроде «fix» или «update» не несут информации. Пишите осмысленно: «Fix memory leak in user service», «Add login endpoint».
Ошибка 05
Работа с одним аккаунтом на несколько проектов или команд
Не смешивайте личные и рабочие проекты в одном аккаунте. Используйте организации для командной работы и разные профили для личных проектов.
Ошибка 06
Неиспользование веток (работа в main)
Работать напрямую в main — антипаттерн. Всегда создавайте ветку для каждой задачи: так вы не сломаете стабильную версию и сможете держать историю чистой.
Рынок / Контекст
GitHub в современных IT-проектах: контекст спроса
GitHub остаётся самой массовой платформой хостинга кода — крупнее GitLab и Bitbucket по числу репозиториев и разработчиков. Владение GitHub — одно из самых распространённых требований в вакансиях разработчиков, DevOps и QA-инженеров, вне зависимости от отрасли и размера компании.
Сокращает ручную работу
GitHub востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Встроен в рабочий процесс
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Закреплён в зрелом стеке
GitHub чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Сигнал рынка
Стабильный спрос
GitHub формирует устойчивый спрос внутри своего рабочего сегмента.
Рынок / Спрос
Спрос на GitHub на рынке
GitHub сохраняет устойчивый прикладной спрос на рынке: 206 активных вакансий, #79 по рынку, 2.9% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
Сила спроса
Стабильный спрос 206
активных вакансий сейчас
#79 по рынку • 2.9% IT-вакансий
Месяц к месяцу
288
июль 2026 — предварительный накопительный срез
-64 вакансий и -18% к предыдущему месяцу.
Доход / Уровни
Зарплаты в вакансиях, где требуется GitHub
GitHub — стандарт для всех техролей в московском IT-срезе: от — (junior) до — (senior). Знание Actions и CI/CD дополнительно повышает ценность.
Медиана рынка
Ограниченная точность 230 000
₽ / месяц
62 вакансий с зарплатой в расширенной зарплатной выборке
Коридор по грейдам
—
уровни с выборкой
Коридор появится, когда по грейдам наберётся достаточная выборка.
Основной уровень
Senior
по структуре рынка
Senior - основной уровень рынка (48%)
Связи / Навыки
Навыки в связке с GitHub
GitHub редко живёт изолированно: чаще всего рынок видит его рядом с CI/CD, Docker, GitLab. Самая плотная связка сейчас - CI/CD: оба навыка встречаются вместе в 56% вакансий.
Главная связка: CI/CD • 56% вакансий. Показываем общерыночные связки GitHub: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
Рабочий стек вокруг GitHub
навыки, которые рынок чаще всего видит рядом в одной вакансии
Навык Зачем рядом Доля
Вход / Старт
Порог входа
Сейчас на рынке 12 активных junior-вакансий с GitHub. Это 7.1% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
Junior-вакансии сейчас
12
активных вакансий
7.1% всех вакансий по навыку • Senior / Junior 6.8x
Доля junior
7.1%
% всех вакансий по навыку
Окно входа узкое: рынок чаще нанимает с опытом.
Что нужно на старте
Стартовый стек
19
навыков в медианной вакансии
Медианная вакансия с GitHub ожидает около 19 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
Карьера / Резюме
GitHub в резюме: что значит "знаю GitHub"
GitHub — это базовый навык для большинства разработчиков. В резюме важно не просто упомянуть «GitHub», а показать, что вы можете делать на платформе: от работы с репозиториями до автоматизации CI/CD.
Уровень Что значит Что показать
Beginner
Умею создавать репозиторий, пушить код, делать коммиты и базовый pull request
«Работаю с Git и GitHub: создание репозиториев, коммиты, ветки, pull request'ы»
Junior developer
Могу вести feature-ветки, проходить code review, работать с issues и решать merge-конфликты
«Опыт работы в команде через GitHub: code review, управление ветками, разрешение конфликтов»
Middle developer
Настраиваю GitHub Actions, защищённые ветки, управляю доступом в organisation, участвую в open source
«Настройка CI/CD через GitHub Actions, управление репозиториями в организации, контрибьюции в open source проекты»
QA automation
Пишу автотесты в GitHub Actions, настраиваю матрицы, работаю с Issues для баг-трекинга
«Автоматизация тестирования через GitHub Actions: матрицы OS, параллельные запуски, кэширование»
Data/ML
Версионирую модели через Git LFS, запускаю переобучение по расписанию, храню ноутбуки
«Версионирование ML-моделей через Git LFS, автоматический перезапуск пайплайнов по расписанию»
DevOps junior
Настраиваю CI/CD, работаю с secrets и environments, управляю ветками и политиками доступа
«GitHub CI/CD: workflows, защищённые ветки, управление секретами и окружениями»
SRE/platform
Управляю organisation-политиками, аудирую доступ, настраиваю Dependabot и CodeQL, работаю с GitOps
«Администрирование GitHub organisation: политики безопасности, аудит, Dependabot, GitOps-деплой»
Сравнение / Инструменты
Инструменты рядом с GitHub
GitHub редко работает один. Рядом находятся Git, система задач, автоматизация, редактор кода и правила команды. У каждого слоя — своя граница.
Инструмент За что отвечает Когда нужен Граница
GitHub
Платформа для PR, review, checks, задач и релизов.
Когда проект меняют командой и нужен общий процесс.
Не заменяет знание Git и качество тестов.
Git
Контроль версий: коммиты, ветки, слияния и откаты.
Когда нужно понимать историю файлов локально и удалённо.
Сам по себе не даёт PR, review и checks.
GitLab
Похожая платформа с собственной экосистемой и CI.
Когда команда уже живёт в GitLab или держит его у себя.
Переход требует новых правил и автоматизации.
GitHub Issues
Слой задач и причин изменения рядом с репозиторием.
Когда PR должен быть связан с понятным контекстом.
Не заменяет проверку кода и статусы сборки.
GitHub Actions
Автоматизация событий внутри репозитория.
Когда тест, сборка или публикация должны запускаться сами.
Нуждаются в аккуратной настройке прав и секретов.
Навык / Применение
Где используется GitHub
GitHub — универсальный инструмент, но каждая роль использует его по-своему.
Сценарий 01
Разработка backend / frontend
Команда ведёт общий репозиторий: каждый разработчик создаёт ветку → коммитит → открывает PR → проходит code review → мёржит. GitHub Actions запускает линтеры, тесты...
Сценарий 02
DevOps / Инфраструктура
Инженеры хранят манифесты Kubernetes, Terraform-код, Ansible-плейбуки. Через GitHub Actions триггерится деплой в облако. Secrets хранятся в зашифрованном виде.
Сценарий 03
QA / Тестирование
Автотесты запускаются на каждый push или PR. Команда QA использует Issues для баг-трекинга, а для регрессионного тестирования — GitHub Actions с матрицами.
Сценарий 04
Data Science и ML
Модели и эксперименты версионируются с помощью Git LFS. Jupyter-ноутбуки хранятся в репозитории, а через GitHub Actions запускается переобучение модели по...
По направлениям
GitHub заметен в 5 направлениях рынка с долей выше 5%.
Направление Контекст Доля
Разработка
Ведение общего репозитория, ветки, PR, code review, GitHub Actions для тестов и сборки.
52.9%
Инфраструктура
Часть спроса по навыку сосредоточена в этом направлении.
15.9%
Данные и ML
Часть спроса по навыку сосредоточена в этом направлении.
10.8%
Тестирование
Часть спроса по навыку сосредоточена в этом направлении.
8%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности
Что нужно уметь в GitHub
GitHub проверяют через командный путь изменения: репозиторий, ветка, pull request, ревью, проверки, доступы, секреты, релиз и восстановление после ошибки.
Репозиторий
Понять структуру, ветки и историю проекта.
Pull request
Описать изменение и собрать review в одном месте.
Checks
Читать статусы тестов, сборки и служебных проверок.
Branch protection
Не давать случайному merge проходить мимо правил.
Secrets и права
Хранить доступы и роли без лишнего риска.
Release flow
Связывать код, версию и заметки о выпуске.
Сравнение / Контекст
GitHub, Git, GitLab и Bitbucket: в чём разница
Сравнивать нужно не логотипы, а ответственность. Git хранит историю, GitHub организует совместную работу, GitLab и Bitbucket закрывают похожие задачи в других экосистемах.
GitHub и Git
Git хранит историю изменений. GitHub добавляет командный слой вокруг этой истории.
GitHub и GitLab
Обе платформы закрывают PR, задачи и автоматизацию. Разница чаще в экосистеме и привычках команды.
GitHub и Bitbucket
Bitbucket часто берут рядом с Jira. GitHub чаще выбирают за экосистему и привычный рабочий процесс.
GitHub и система задач
Трекер объясняет причину работы. Репозиторий показывает реализацию и историю её проверки.
Данные / Стек
Опорные объекты GitHub
Разбор GitHub начинается с цепочки следов. Репозиторий показывает файлы и историю, задача объясняет причину, ветка отделяет работу, pull request собирает обсуждение, а checks фиксируют автоматический результат. Если смотреть только на код, легко потерять контекст: зачем изменение сделали, кто принял риск и какой тест его вообще проверял. Поэтому рабочая диагностика почти всегда связывает несколько объектов сразу, а не один экран.
Репозиторий
Показывает файлы, историю и ветки.
Issue
Объясняет причину и контекст изменения.
Pull request
Собирает discussion и ревью вокруг правки.
Checks
Фиксируют автоматический результат на ветке.
Actions log
Показывает, где и почему упала автоматизация.
Release
Связывает merge с конкретной версией.
Практика / Workflow
Как GitHub используется в реальном проекте
Этап Что происходит Артефакт
1 Планирование
Создание Issue с описанием задачи, назначение на исполнителя, привязка к milestone
Issue
2 Разработка
Создание feature-ветки от main, написание кода и коммиты
feature-branch
3 Pull Request
Описание изменений, запрос code review, обсуждение и исправление замечаний
PR с комментариями
4 CI / тестирование
GitHub Actions запускает линтеры, тесты, сборку. Результаты отображаются в PR
Workflow run
5 Code review
Тимлид или участник проверяет код, оставляет комментарии, утверждает (approve) или запрашивает изменения
Approved PR
6 Мёрж в main
После аппрува и прохождения всех проверок PR вливается в main. Ветка удаляется
Main branch
7 Деплой
GitHub Actions или GitOps-инструмент запускает деплой на staging/prod после мёржа или по тегу
Release
8 Пост-релиз
Создание релизного тега, публикация артефактов, уведомление команды
Release + notes
Инструмент / Оркестрация
GitHub Actions: рабочие процессы и автоматизация
GitHub Actions — это встроенная CI/CD-система. Вы описываете workflow в YAML-файле .github/workflows/*.yml, и GitHub запускает его при наступлении события (push, pull_request, release, schedule).
name / идентификатор workflow
Имя, отображаемое на вкладке Actions. Позволяет различать несколько workflow'ов в одном репозитории.
on / триггеры
События, которые запускают workflow: push, pull_request, release, schedule (cron-расписание) или ручной trigger (workflow_dispatch).
jobs / задачи
Набор задач, которые могут выполняться параллельно или последовательно. Каждая задача имеет runs-on (окружение) и steps (шаги).
runs-on / окружение
Указывает виртуальную машину: ubuntu-latest, windows-latest, macos-latest или самодельный self-hosted runner.
steps / шаги
Каждый шаг может использовать готовый action (через uses) или выполнить произвольную команду (через run).
Пример: минимальный CI для Python
Checkout кода → настройка Python → установка зависимостей → запуск тестов. Весь workflow помещается в один YAML-файл.
Окружения (environments)
Позволяют задать разные правила для staging и production: обязательные ревьюеры, зашифрованные переменные, защищённые ограничения.
Рекомендации по production
Используйте matrix для тестирования на нескольких версиях языка. Для деплоя применяйте окружения с обязательными проверками и approval gates.
Практика / GitHub
GitHub: лучшие практики и ошибки новичков
Практика 01
Правило защищённой ветки (protected branch)
Включите «Require pull request reviews» и «Require status checks» в настройках main-ветки. Это предотвращает прямой пуш и гарантирует, что каждый PR прошёл code review.
Практика 02
Не храните секреты в коде (secrets)
Используйте `secrets.GITHUB_TOKEN` и secrets на уровне репозитория или окружения. Никогда не хардкодьте токены, пароли или API-ключи в скриптах.
Практика 03
Пишите осмысленные commit-сообщения
Начинайте с глагола в повелительном наклонении: «Add login page», «Fix memory leak». Сообщение должно объяснять ЧТО и ПОЧЕМУ, не повторяя код.
Практика 04
Используйте .gitignore с начала проекта
Добавьте стандартный `.gitignore` для вашего языка (Python, Node, Java). Это предотвратит попадание папок node_modules, `.env` и артефактов сборки в репозиторий.
Практика 05
Делайте PR небольшими и частыми
Один PR — одна фича или исправление. Большие PR (500+ строк) трудно ревьюить. Разбивайте задачи на логические единицы и отправляйте по мере готовности.
Практика 06
Настройте Dependabot для обновления зависимостей
Dependabot автоматически создаёт PR при выходе новых версий пакетов. Это повышает безопасность и упрощает обновление библиотек.
Практика 07
Оптимизируйте GitHub Actions: кэширование
Кэшируйте зависимости между запусками (actions/cache). Для Python — `pip cache`, для Node — `node_modules`. Это сокращает время выполнения workflow в несколько раз.
Практика 08
Используйте матрицы (matrix strategy) для тестов
Запускайте тесты на разных OS и версиях языка в параллельных задачах. Это гарантирует совместимость и быстрее выявляет платформенные баги.
Практика / Безопасность
Безопасность GitHub: что нельзя делать
Риск 01
Не храните секреты в файлах репозитория
Пароли и API-ключи, закоммиченные в код, остаются в истории Git навсегда. Используйте GitHub Secrets и окружения для конфиденциальных данных.
Риск 02
Избегайте переиспользования персональных access-токенов
Каждый токен — для конкретной цели. Используйте fine-grained tokens с минимальными разрешениями. Отзывайте неиспользуемые токены.
Риск 03
Не давайте лишние права коллабораторам
Назначайте минимально необходимые роли: Read для просмотра, Write для пуша, Admin только для управляющих. Избегайте прав Admin для всех участников.
Риск 04
Включайте двухфакторную аутентификацию (2FA)
Обязательная 2FA снижает риск взлома аккаунта. В организации можно принудительно включить 2FA для всех участников.
Риск 05
Сканируйте код на уязвимости (CodeQL, Dependabot)
CodeQL находит ошибки безопасности в коде, Dependabot уведомляет об уязвимых зависимостях. Включите оба инструмента в репозиторий.
Риск 06
Не используйте GitHub Issues как базу данных паролей
Issues — это публичное обсуждение. Если нужно обсудить секрет, используйте зашифрованные каналы или GitHub Secrets, а не комментарии в Issue.
Риск 07
Защищайте main-ветку от случайного пуша
Включите защищённую ветку (protected branch) с обязательным code review и проверками CI. Это предотвращает случайное попадание багов в продакшн.
Риск 08
Проверяйте fork'и перед мёржем PR
PR из fork'ов могут содержать вредоносный код. Всегда проверяйте, что PR получен от доверенного участника, и запускайте тесты в CI перед мёржем.
Будущее / Роль
Перспективы GitHub
Перспективы GitHub завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Сигнал 01
Copilot + AI-ассистент
GitHub Copilot — AI-помощник для написания кода на основе контекста. В будущем станет умнее, интегрируется глубже в Actions и процессы code review.
Сигнал 02
Расширение GitHub Actions
Actions превращаются в универсальную платформу автоматизации — не только CI/CD, но и управление проектами, безопасность и compliance.
Сигнал 03
Усиление безопасности (CodeQL, Dependabot)
GitHub всё активнее внедряет встроенную безопасность: автоматическое сканирование кода, управление уязвимостями, улучшенные политики доступа.
Практика / Портфолио
Портфолио с GitHub: с чего начать
Проект 01
Блог на GitHub Pages
Создать репозиторий username.github.io, написать статический сайт (HTML/CSS/JS) и опубликовать его. Критерий готовности: сайт доступен по адресу username.github.io.
Проект 02
CI/CD для Python-проекта
Написать GitHub Actions workflow: checkout, настройка Python, установка зависимостей, запуск тестов. Критерий: workflow успешно проходит на каждый push в main.
Проект 03
Open Source contribution
Найти проект с меткой «good first issue», форкнуть, создать PR с небольшим исправлением документации или кода. Критерий: PR принят мэйнтейнером.
Проект 04
Multi-service project с Docker и CI
Создать проект с несколькими сервисами (Flask + Redis + PostgreSQL), описать Docker Compose и настроить GitHub Actions для сборки и публикации образов. Критерий: workflow собирает образы и пушит их в GitHub Container...
Проект 05
Protected branches + Dependabot
Настроить в репозитории защиту main-ветки: обязательное code review и проверки CI. Включить Dependabot. Критерий: прямой пуш в main запрещён, Dependabot создаёт PR при выходе новой версии зависимости.
Проект 06
GitHub Actions matrix для кросс-платформенных тестов
Настроить matrix strategy: запускать тесты на ubuntu-latest, windows-latest, macos-latest. Критерий: все три платформы выполняют тесты за один workflow.
Обучение / Маршрут
Как изучить GitHub
GitHub — один из самых быстрых для освоения инструментов. Базовый навык (создать репозиторий, сделать commit и PR) можно получить за вечер. Более глубокие знания (GitHub Actions, защита веток, работа с большими open source проектами) требуют практики, но не сложных теорий.
Этап Фокус Что изучать
Этап 01
Git-основы для GitHub
Изучите базовые команды Git: clone, add, commit, push, pull, branch, merge. Поймите, как работает локальный репозиторий и как он связывается с удалённым...
Этап 02
Базовый GitHub
Научитесь создавать репозиторий, пушить код, открывать Pull Request, проходить code review. Пользуйтесь GitHub Issue для баг-трекинга.
Этап 03
GitHub Actions: CI/CD
Напишите свой первый workflow: автоматические тесты для вашего проекта. Разберитесь с триггерами, jobs, matrix strategy и кэшированием.
Этап 04
Безопасность и совместная работа
Настройте защищённые ветки (protected branches), используйте secrets, настройте Dependabot и CodeQL. Участвуйте в open source: форкайте проекты и...
Курсы · по данным рынка
Курсы и документация по GitHub: как выбирать
Соответствие — доля тем навыка, которые охватывает программа курса
Практика / Первый запуск
С чего начать изучение GitHub
Стартуйте с маленького репозитория и одного изменения. Создайте задачу, ветку, коммит и pull request, а затем добавьте простую автоматическую проверку. После первого успешного merge обязательно пройдите ещё один маршрут: красный статус, конфликт, новое ревью и выпуск тега. Именно на этом цикле становится ясно, зачем GitHub нужен поверх обычного Git. Без него платформа быстро воспринимается как ещё один сайт для кода, а не как рабочий процесс команды. А после такого цикла уже понятнее, где ценность review и checks. Заодно становится ясно, как проект переживает неидеальное изменение. И кто именно отвечает за выпуск после merge.
Шаг 01
Создайте репозиторий
Добавьте README, простую задачу и один файл, который можно изменить. Сразу определите основную ветку и правило для изменений.
Шаг 02
Сделайте ветку
Внесите небольшую правку, сделайте понятный коммит и отправьте ветку в удалённый репозиторий.
Шаг 03
Откройте pull request
Опишите, зачем нужна правка, как её проверить и какой риск есть. Свяжите карточку с задачей.
Шаг 04
Добавьте проверку
Настройте GitHub Actions или другую проверку так, чтобы её статус был виден в pull request и влиял на слияние.
Шаг 05
Зафиксируйте правила
Включите защиту ветки, разберите конфликт и создайте релиз, чтобы увидеть весь путь изменения до версии продукта.
Старт / Документация
Официальные ресурсы и быстрый старт
Для инструментов вроде GitHub на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Частые вопросы
Вопросы и ответы
Что такое GitHub простыми словами?
GitHub — это облачный сервис для хранения кода и совместной работы, построенный вокруг системы контроля версий Git. Представьте Google Docs для разработчиков, где каждое изменение сохраняется и можно откатиться назад.
Чем GitHub отличается от Git?
Git — инструмент, работающий локально на вашем компьютере. GitHub — веб-платформа, которая делает Git удобным для команд: даёт резервные копии, пул-реквесты, управление задачами.
Нужен ли GitHub для личных проектов?
Не обязательно, но полезно. Даже для одного разработчика GitHub даёт резервное копирование, удобный просмотр кода, GitHub Pages для портфолио и возможность показать проект рекрутерам.
Как создать репозиторий на GitHub?
Нажмите зелёную кнопку «New» на странице репозиториев, задайте имя, выберите публичный/приватный, инициализируйте с README или без — и готово. Затем клонируйте его на свой компьютер через git clone.
Что такое pull request?
Pull Request — это запрос на вливание изменений из одной ветки в другую. Вы сделали изменения в своей ветке, затем открываете PR, и команда обсуждает код, прежде чем объединить с main.
Как сделать fork репозитория?
На странице чужого репозитория нажмите кнопку «Fork» в правом верхнем углу. Создаётся копия под вашим аккаунтом, которую можно свободно менять и предлагать изменения через PR.
Что такое GitHub Actions?
Это встроенная система CI/CD для автоматизации тестов, сборки и деплоя. Вы описываете workflow в YAML, и GitHub запускает его на push, PR или по расписанию.
Бесплатный ли GitHub?
Да, базовый бесплатный план включает неограниченное количество публичных и приватных репозиториев с неограниченным числом участников, 2000 минут GitHub Actions в месяц и другие функции.
Как опубликовать сайт на GitHub Pages?
Создайте репозиторий с именем username.github.io (заменив username на ваш логин), поместите туда HTML/CSS/JS, включите GitHub Pages в настройках репозитория — сайт станет доступен по адресу username.github.io.
Что такое .gitignore?
Файл, в котором перечисляются файлы и папки, которые Git должен игнорировать (например, node_modules, .env, собранные артефакты). Это предотвращает попадание ненужных файлов в репозиторий.
Как откатить изменения в Git/GitHub?
Можно использовать git revert для отмены одного коммита, git reset для перемещения указателя ветки назад, или в веб-интерфейсе GitHub нажать «Revert» на странице PR.
Что такое Issues в GitHub?
Это задачи, баг-репорты, предложения по улучшению. Issues можно назначать, маркировать тегами (labels), привязывать к milestone, комментировать и связывать с PR.
Как работать над open source проектом?
Форкните репозиторий, склонируйте его, создайте ветку, внесите изменения, отправьте PR. Обычно проекты имеют CONTRIBUTING.md с правилами и CODE_OF_CONDUCT.md.
Чем GitHub Enterprise отличается от обычного GitHub?
GitHub Enterprise — это решение для организаций, которое можно развернуть на своих серверах (Server) или в облаке (Cloud). Включает расширенную безопасность (SSO, audit log), круглосуточную поддержку и SLA.
Как защитить ветку main от случайных правок?
В настройках репозитория (Settings > Branches) добавьте правило защиты ветки: включите «Require pull request reviews», «Dismiss stale reviews», «Require status checks». Тогда никто не сможет пушить напрямую в main.
Что такое GitHub Codespaces?
Облачная среда разработки на основе VS Code. Позволяет начать кодить без настройки локальной машины — всё окружение разворачивается в облаке за секунды.
Как управлять версиями релизов в GitHub?
Используйте Releases: создавайте тег (например, v1.0.0), пишите описание изменений и прикрепляйте бинарные артефакты. Для автоматизации — Actions с триггером release.
Что такое GitHub Packages?
Реестр пакетов, встроенный в GitHub. Поддерживает npm, Docker, Maven, NuGet, RubyGems. Позволяет публиковать артефакты прямо из репозитория и управлять доступом.
Как быстро найти чужой репозиторий?
Используйте поиск GitHub по названию, опции «Stars:>1000» и теги (language, topic). На странице профиля можно увидеть все публичные репозитории пользователя.
Что делать, если я случайно закоммитил секретный ключ?
Немедленно отзовите ключ. Используйте BFG Repo-Cleaner или git filter-repo (современная замена устаревшего git filter-branch) для удаления из истории. Затем свяжитесь с GitHub Support, если ключ мог просочиться в публичный репозиторий.
Что такое GitHub Projects и как их использовать?
Канбан-доски для управления задачами. Позволяют планировать итерации, назначать участников, связывать задачи с Issues и PR. Доступны в режиме Table, Board и Roadmap.
Как участвовать в Code Review?
После открытия PR просмотрите изменённые файлы, оставьте комментарии по строкам кода, предложите улучшения. После одобрения нажмите «Approve» или запросите изменения.
Что такое Git LFS и зачем он нужен?
Large File Storage — расширение для работы с большими файлами (больше 50 МБ). Заменяет файл ссылкой-заглушкой в Git, а содержимое хранит в отдельном хранилище.
Как скрыть приватный репозиторий от поисковиков?
Приватный репозиторий по умолчанию не виден никому, кроме владельца и приглашённых коллабораторов. Для дополнительной безопасности используйте organisation с ограниченным доступом.
Что такое GitHub Discussions?
Форум для обсуждения вопросов, идей и предложений. Альтернатива Issues для общих обсуждений и вопросов к сообществу.
Как в GitHub Actions получить дату или номер релиза?
Используйте переменные окружения: GITHUB_REF_NAME для названия ветки/тега, GITHUB_SHA для хеша коммита. Для даты — команда date внутри шага.
Что такое GitHub Secret Scanning?
Автоматический поиск закоммиченных паролей, API-ключей, токенов в репозиториях. При обнаружении уязвимости GitHub уведомляет владельца и может отправить алерт.