Командная работа и практики — Git

Стратегии ветвления

GitHub Flow

Самая простая и популярная схема:

main всегда рабочий и готов к выкату.
Для каждой задачи создается короткая ветка от main.
Открывается Pull Request, проходит ревью и проверки.
После слияния в main код выкатывается.

1main:    A---B-------M---N2              \     /3feature:       C---D

Подходит большинству команд и веб-проектов с постоянной поставкой.

Trunk-based development

Все работают почти напрямую в main, ветки живут не дольше одного-двух дней. Незаконченные функции прячут за флагами возможностей (feature flags). Требует хорошей автоматизации и тестов. Используется в крупных командах с частыми релизами.

Git Flow

Много долгоживущих веток:

1main        — только релизы, помечены тегами2develop     — общая интеграция3feature/*   — задачи, от develop4release/*   — подготовка релиза5hotfix/*    — срочные исправления, от main

Подходит для продуктов с версионными релизами (мобильные приложения, библиотеки, десктоп). Для веб-сервисов обычно избыточен.

Что выбрать

Ситуация	Схема
Веб-сервис, частые деплои	GitHub Flow или trunk-based
Несколько поддерживаемых версий	Git Flow или релизные ветки
Маленькая команда, учебный проект	GitHub Flow

Pull Request

Pull Request (PR, в GitLab — Merge Request) — запрос на слияние ветки с обсуждением и проверками.

Порядок:

1git switch -c feature/search2git add .3git commit -m "Add search endpoint"4git push -u origin feature/search

Затем откройте PR на GitHub. Если установлен GitHub CLI:

1gh pr create --fill2gh pr checkout 423gh pr merge 42 --squash

Хороший Pull Request

небольшой: до 200–400 строк, одна задача;
с описанием: что сделано, зачем, как проверить, ссылка на задачу;
с зелеными проверками: тесты и линтеры проходят;
самопроверен: вы сами просмотрели diff до запроса ревью;
в draft режиме, пока не готов.

Шаблон описания:

 1## Что сделано 2Добавлен поиск по каталогу. 3 4## Зачем 5Задача PROJ-123: пользователи не могут найти товары. 6 7## Как проверить 81. Открыть /catalog 92. Ввести слово в поле поиска1011## Скриншоты и заметки

Способы слияния PR

Способ	Результат	Когда
Merge commit	сохраняет все коммиты и добавляет merge	нужна полная история
Squash and merge	все коммиты ветки в один	чистая история, много мелких коммитов
Rebase and merge	линейная история, коммиты сохраняются	аккуратные коммиты в ветке

Для большинства команд удобен Squash and merge: один PR — один коммит в main.

Code review

Для автора:

отвечайте на комментарии спокойно, правьте или объясняйте;
не переписывайте историю во время ревью без нужды, так тяжелее смотреть изменения.

Для ревьюера:

проверяйте логику, граничные случаи, безопасность, тесты, читаемость;
критикуйте код, а не человека;
разделяйте блокирующие замечания и пожелания («nit:»);
отвечайте быстро: долгие ревью тормозят команду.

Сообщения коммитов: Conventional Commits

Единый формат помогает читать историю и автоматически генерировать changelog и версии:

1тип(область): описание23тело45подвал

Типы:

Тип	Назначение
`feat`	новая функциональность
`fix`	исправление ошибки
`docs`	документация
`refactor`	изменение кода без смены поведения
`test`	тесты
`chore`	служебные изменения, зависимости
`perf`	улучшение производительности
`ci`	настройки CI

Примеры:

1feat(auth): add login via email2fix(cart): prevent negative quantity3docs: update install instructions4feat(api)!: remove deprecated v1 endpoints

Знак ! или подвал BREAKING CHANGE: означают несовместимое изменение.

Правила репозитория

Настройте в GitHub: Settings → Branches → Branch protection rules (или Rulesets) для main:

запрет прямого push, только через Pull Request;
минимум одно одобрение ревью;
обязательные проверки CI перед слиянием;
запрет force push и удаления ветки;
требование актуальной ветки перед слиянием;
опционально: подписанные коммиты, линейная история.

CODEOWNERS

Файл .github/CODEOWNERS назначает ответственных за части кода. Они автоматически добавляются в ревьюеры:

1*                @team-lead2/backend/        @backend-team3/frontend/       @frontend-team4/.github/        @devops

Что хранить в репозитории

Должно быть:

исходный код и тесты;
README.md: что это, как запустить, как внести вклад;
.gitignore;
LICENSE для открытых проектов;
конфигурация CI/CD;
.env.example без реальных значений;
CONTRIBUTING.md с правилами команды.

Не должно быть:

секретов: паролей, токенов, ключей, .env;
зависимостей (node_modules, target) и сборки;
больших бинарных файлов, для них используют Git LFS;
личных настроек IDE.

Ежедневные привычки

Начинайте день с git pull --rebase.
Коммитьте часто и небольшими порциями.
Перед коммитом смотрите git status и git diff --staged.
Не работайте долго в ветке без синхронизации с main.
Не коммитьте код, который не компилируется или ломает тесты.
Удаляйте слитые ветки.
Перед силовыми операциями (reset --hard, push --force) остановитесь и подумайте.