GitHub — облако для кода и команд

1. GitHub и Git — в чём разница

Git — система контроля версий, работает локально (курс Git). GitHub — сервис, который хранит Git-репозитории в облаке и добавляет команде инструменты: Issues, PR, Actions, Projects. То же умеет GitLab — корпоративная альтернатива.

2. Подготовка доступа: SSH или HTTPS

Создай аккаунт на github.com. Дальше два способа аутентификации:

• SSH — рекомендуемый: один раз сгенерировал ключ и добавил в аккаунт;
• HTTPS — проще для начала, но просит креды (или Personal Access Token) в каждой операции.

# генерация SSH-ключа
ssh-keygen -t ed25519 -C "you@example.com"
# показать публичный ключ → скопировать на github.com → Settings → SSH keys
cat ~/.ssh/id_ed25519.pub

# проверить подключение
ssh -T git@github.com
# → Hi username! You've successfully authenticated…

3. Создание репозитория и первый push

gh repo create my-project --public --source . --push
# или вручную:
git init
git add .
git commit -m "Инициализация проекта"
git remote add origin git@github.com:username/my-project.git
git push -u origin main

Полезные файлы в репозитории:

README.md         # описание проекта, инструкция
LICENSE           # лицензия (MIT, Apache 2.0…)
.gitignore        # node_modules, dist, .env — не в Git
CODE_OF_CONDUCT.md# правила общения (open source)

4. Рабочий процесс: ветки и PR

Стандарт командной разработки — GitHub Flow:

1. создай ветку фичи от main;
2. коммить и пушить в свою ветку;
3. открой Pull Request (PR) в main;
4. команда ревьюит, обсуждает diff, предлагает правки;
5. после аппрувов PR вливается (merge или squash).

git checkout -b feature/login
git add . && git commit -m "Добавить страницу входа"
git push -u origin feature/login   # GitHub предложит создать PR

5. Issues и Projects

Issues — трекер задач: баг-репорты, фичи, вопросы. Формат — markdown, с лейблами, мильстоунами и автосвязью с PR (#42 закрывает issue). Projects — канбан-доску (To Do / In Progress / Done) поверх issues.

// привязка PR к issue в описании PR
Closes #42
// или в коммите
git commit -m "Исправить баг (#42)"

6. Code review: правила PR

• один PR = одна задача, не больше 300–500 строк diff;
• описывай «что и зачем», прикладывай скриншоты UI;
• ревьюер ставит comment, approve или request changes;
• дожидайся зелёных checks (тесты, линтер) перед merge.

7. GitHub Actions — CI/CD

Actions — встроенный CI/CD. Workflow — YAML-файл в .github/workflows:

// .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run lint
      - run: npm test

После запуска к шагам PR появится галочка. Можно добавлять деплой, публикацию пакетов, артефактов и уведомления.

8. GitHub Pages — бесплатный хостинг

Pages публикует статический сайт из репозитория: Settings → Pages → «Deploy from a branch» → ветка main, папка /root или /docs. Сайт получишь по адресу https://username.github.io/repo/.

# Новая страница разворачивается автоматически при push
git add . && git commit -m "Обновить страницу" && git push

9. Releases и теги

git tag v1.0.0
git push origin v1.0.0

Тег (tag) — метка коммита. На теги можно прикрепить Release: чендж-лог, архивы, установщики. Семантическое версионирование: MAJOR.MINOR.PATCH.

10. Полезные привычки

• никогда не пушить напрямую в main;
• fork + PR — путь к опенсорсу;
• profile README — визитка аккаунта;
• добавляй .gitignore до первого push.

# .gitignore: база для Node.js
node_modules/
dist/
.env
.env.*
*.local
npm-debug.log*

11. Защита веток и правила слияния

Уверенность в main даёт branch protection — правила, которые запрещают прямые пуши и заставляют всё идти через PR:

Settings → Branches → Add rule
- Require a pull request before merging
- Require status checks (CI, тесты, линтер)
- Require approvals (1–2 ревьюера)
- Do not allow bypassing

Когда включены статус-чеки, ветку нельзя слить, пока проверка не прошла. Approvals требуют явного одобрения ревьюеров.

• Require conversation resolution — комментарии нельзя закрыть без ответа;
• Require linear history — только squash/merge, история становится плоской;
• Require signed commits — гарантия авторства через GPG.

12. Организации и управление командой

Набор репозиториев компании удобно держать в Organisation — общем аккаунте, где доступ выдаётся командам и ролям, а не отдельным людям:

Принцип минимальных прав: разработчику чаще всего хватает Write, мейнтейнерам — Maintain, а Admin оставляют узкому кругу.

Org → Settings → Teams → создать команды
backend, frontend, devops
→ назначить репозитории и роли

13. Webhooks и интеграции

Webhook — HTTP-вызов стороннего сервиса при событии в репозитории: push, открытие PR, создание issue. Так GitHub извещает ваш бэкенд о событиях в реальном времени.

Settings → Webhooks → Add webhook
Payload URL: https://my-server.ru/gh/hook
Content type: application/json
Events: push, pull_request, issues

Событие приходит как JSON-запрос с типом в заголовке X-GitHub-Event:

{ "action": "opened",
  "pull_request": { "html_url": "...", "title": "..." },
  "repository": { "full_name": "user/repo" } }

Типовые сценарии: уведомления в чат, автодобавление лейблов, обновление внешней документации, деплой по событию (хотя для CI обычно используют GitHub Actions).

14. Опенсорс: лицензии и README

Публичный репозиторий — это мини-продукт. Минимальный опенсорс-набор:

• LICENSE — без неё код юридически «все права защищены», делиться нельзя;
• README.md — что делает проект, как установить и запустить;
• CONTRIBUTING.md — гайд для контрибьюторов;
• CODE_OF_CONDUCT.md — правила поведения сообщества.

// README: секция «Как начать»
## Installation
npm install my-lib
## Usage
import { util } from "my-lib";
util();

Популярные лицензии: MIT (простая пермиссивная), Apache-2.0 (с патентной оговоркой), GPL (copyleft), BSL (для продуктовой монетизации).

15. gh CLI и GitHub API

Официальный CLI gh закрывает весь цикл из терминала: создание репозитория, PR, issues, запуск Actions, релизы. Привыкнув к нему, перестанешь ходить в браузер для рутины:

gh auth login
gh repo create my-app --public --source . --push
gh pr create --title "Добавить логин" --body "Closes #12"
gh pr checkout 42
gh run watch
gh release create v1.0.0

gh работает поверх REST API GitHub. Для скриптов удобнее сам API: запрос к https://api.github.com с заголовком Authorization и токеном. Типовые сценарии: генерация чендж-лога из merged-PR (gh pr list --merged), массовое открытие issues из файла, шаблоны PR через --template.

16. Безопасность: Dependabot и сканеры

Полноценный GitHub для команд включает и защиту зависимостей. Встроенные инструменты:

Dependabot следит за npm, pip, Maven и другими экосистемами по базе GitHub Advisory Database, а обновление приходит пул-реквестом с указанием версии. CodeQL ищет инъекции и небезопасные паттерны в Python, JS, Java, Go и C#, запускаясь из Actions.

17. Монорепо и большие репозитории

Когда репозиторий растёт, GitHub вводит ограничения: до 100 МБ на файл и рекомендованный размер до 1 ГБ. Избегай раздувания:

• не коммить бинарники и артефакты — они навсегда увеличивают историю;
• для больших файлов используй Git LFS или внешнее хранилище (S3);
• в монорепо применяй path-фильтры в Actions: сборка запускается только для изменённых пакетов (paths: ['backend/**']);
• удаляй закрытые ветки после merge — иначе клон репозитория тормозит.

Для навигации по большим проектам работают code search по организации и схема зависимостей репозитория (dependency graph).

18. Типовые ошибки новичков

• пуш напрямую в main — лечится защитой веток из раздела 11;
• коммит секретов и .env — меняй ключи при малейшем подозрении на утечку;
• огромные PR на тысячи строк — ревьюеры не успевают их прочитать;
• перезапись общей истории (force push) без согласования — ломает работу команды;
• тяжёлые файлы в истории — медленный клон и страницы;
• не обновлённый перед push main — конфликты всплывают в самый неподходящий момент;
• issues без шаблона — багрепорты без контекста не воспроизводятся.

Чек-лист перед push: в статусе нет секретов, коммит описывает изменение, ветка синхронна с main, линтер и тесты прошли, ревьюер назначен.

Что дальше

Начни с команд Git — курс Git. Освоив ветки и коммиты, заведи проект на Vite или Webpack, подключи тесты Jest/Vitest, линтер ESLint и CI в Actions. Для корпоративных задач сравни с курсом GitLab.

← Вернуться к курсам