Pull request, который быстро проверят
Ревьюер — занятой человек. PR на 2000 строк он прочитает поверхностно и напишет «Looks good». Чтобы ревью было полезным:
- маленький PR — до нескольких сотен строк, одна задача; рефакторинг и новая функция — разными PR;
- описание: что сделано и зачем (ссылка на задачу), как проверить, на что обратить внимание, скриншоты для интерфейса;
- самопроверка диффа и зелёный CI до того, как звать людей;
- ветка актуальна с main.
Черновик (draft) открывают рано, чтобы получить отзыв на подход, пока переделывать дёшево. На замечания отвечают по существу: исправить или объяснить, почему иначе. Каждый комментарий закрывают ответом или отметкой «решено».
Ревью по существу, а не по вкусу
Порядок важности:
- Правильность — решает ли задачу, крайние случаи, обработка ошибок.
- Безопасность — ввод, права, секреты.
- Данные и совместимость — миграции, изменения API.
- Тесты — проверяют ли они поведение.
- Поддерживаемость — понятность, сложность, дублирование.
Стиль и форматирование — работа линтера, а не человека. Комментарии конкретные, с причиной, вариантом и пометкой важности: «блокирует», «можно позже», «мелочь». Вопрос работает лучше приказа: «что будет, если список пустой?» Ревью проверяет код, а не автора: «здесь гонка», а не «ты не подумал».
Отвечать на ревью нужно быстро — PR, который ждёт два дня, тормозит всю команду. И отмечать хорошее: ревью — ещё и обучение.
Trunk-based и GitFlow
GitFlow — долгоживущие ветки develop и main, отдельные ветки фич, релизов и хотфиксов. Подходит продуктам с редкими версионированными релизами — мобильным приложениям, коробочному ПО. Цена — большие слияния и поздние конфликты.
Trunk-based development — короткие ветки на часы или день-два, частое слияние в main, main всегда готов к выкатке. Незаконченное прячут за feature flags: код уже на проде, но функция выключена. Флаг позволяет включить её для 1 % пользователей или для сотрудников. После раскатки флаг удаляют, иначе копится долг.
GitHub Flow — упрощённый вариант: ветка → PR → ревью → main → деплой.
CI/CD
CI — каждое изменение автоматически собирается и проверяется: сборка, линтеры, тесты, проверка зависимостей, сборка артефакта — например, образа.
CD бывает двух видов:
- continuous delivery — артефакт всегда готов, на прод — по кнопке;
- continuous deployment — каждое изменение, прошедшее проверки, уходит на прод автоматически.
Главный принцип — собрать один раз и продвигать тот же артефакт через окружения. Версия артефакта — из коммита, а не latest. Дешёвые проверки идут первыми, весь пайплайн — в пределах 10–15 минут. Красный main — приоритет команды: пока он сломан, никто не выкатывает.
Что запомнить
- Маленький PR с понятным описанием и зелёным CI.
- Ревью — по важности: правильность, безопасность, данные, тесты, остальное.
- Короткие ветки и флаги вместо долгих веток.
- Один артефакт проходит все окружения.