Pull request и код-ревью

Основа с Junior

Как команды вливают изменения — ветки, pull request, ревью, автоматические проверки и стратегии ветвления.

Типичный процесс: короткая ветка от main → pull request → CI запускает тесты и линтеры → ревью коллег → слияние → автоматическая выкатка.

Маленькие PR ревьюят быстро и внимательно; PR на 2000 строк одобряют не читая.
Описание PR: что и зачем изменено, как проверить, скриншоты для интерфейса.
Ревью ищет ошибки, проблемы поддержки и безопасности, а не спорит о вкусе — стиль проверяют линтер и форматтер.
Стратегии: trunk-based (короткие ветки, частые слияния, feature flags) или GitFlow (develop, release-ветки) — первая лучше подходит для частых выкаток.
Конфликты разрешают локально: подтянуть основную ветку, исправить, прогнать тесты.
Squash при слиянии превращает ветку в один аккуратный коммит.

Критерии освоения

Практика. Сделать 5 pull request в учебный или открытый проект с описанием и пройти ревью.

Практика. Отревьюить 10 чужих pull request с письменными замечаниями и разобрать с автором самые спорные.

Чем trunk-based development отличается от GitFlow? Middle
GitFlow — долгоживущие ветки develop и main, ветки фич, релизов и хотфиксов; подходит для продуктов с редкими версионированными релизами (коробка, мобильные приложения), но…
Из каких этапов состоит CI/CD-пайплайн и чем continuous delivery отличается от continuous deployment? Junior
CI — каждое изменение автоматически собирается и проверяется: сборка, линтеры, юнит-тесты, сканирование, сборка артефакта (образа). CD: continuous delivery — артефакт всегда готов…

Закрытая бета

На живом собеседовании sotto слышит вопрос интервьюера и показывает короткий ответ и план. Оставьте контакт — пришлём доступ и промокод.