Командная разработка: ветки, мёрж-реквесты и процесс ревью

21.05.2026

Работа в команде над одним проектом — это не просто «все пишут код и пушат». Это живой процесс, который ломается без договорённостей. Ниже — практическое руководство по тому, как устроен нормальный командный процесс: от веток до фича-флагов.

Ветки: master, test и feature

В большинстве команд используют несколько постоянных веток и много короткоживущих.

Постоянные ветки

Ветка	Назначение
`main` / `master`	Production-код. Всегда рабочий, всегда задеплоен.
`develop` / `test`	Интеграционная ветка. Сюда сливаются фичи перед выходом в прод.
`staging`	Опционально. Предрелизная среда, максимально приближена к проду.

Feature-ветки

Каждая новая задача живёт в своей ветке. Принято называть их по шаблону:

feature/название-задачи
fix/описание-бага
chore/технический-долг

Ветка создаётся от develop, в неё идут все коммиты по задаче, потом открывается MR обратно в develop. В master напрямую не пушат никогда — только через ревью и CI.

Как часто делать мёрж-реквест

Короткий ответ: часто и маленькими кусками.

Почему это важно

Большой MR (500+ строк) — это боль для ревьюера. Человек физически не может держать в голове весь контекст такого изменения, ревью становится формальным, а ошибки проскальзывают.

Практические ориентиры

Идеальный MR — 200–400 строк изменений, одна логическая задача.
Максимум — 600–800 строк. Если больше, стоит разбить на части.
По времени — не держать ветку открытой больше 3–5 рабочих дней без MR. Чем дольше ветка живёт отдельно, тем больнее мёрж.

Когда открывать MR

Задача завершена и работает локально.
Написаны тесты (или есть явная причина, почему их нет).
Нет очевидных «TODO: доделать потом» в коде.
CI проходит зелёным.

Некоторые команды практикуют Draft MR (черновик) — открывают реквест раньше, чтобы получить ранний фидбек по архитектуре. Это нормально, главное пометить его как черновик явно.

Синхронизация внутри команды

Фронтенд ↔ Фронтенд

Если несколько фронтендеров работают над одним проектом, они должны регулярно подтягивать изменения друг друга:

Ребейзиться от develop каждый день с утра, до начала работы — это норма.
Если ветки пересекаются по файлам (компоненты, стили, роутинг) — синхронизироваться чаще, буквально каждые несколько часов.
Договариваться заранее: «я трогаю Header, ты не лезь». Звучит банально, но экономит часы на конфликтах.

Фронтенд ↔ Бэкенд

Здесь синхронизация через контракт, а не через ветки:

Сначала договариваются об API — формат запросов, ответов, статус-коды. Фиксируют в OpenAPI/Swagger или просто в Notion/Confluence.
Фронт мокает ответы бэкенда и работает параллельно.
Интеграция — когда бэкенд готов и MR смержен в develop, фронт переключается на реальные эндпоинты.

Ждать бэкенд, ничего не делая — потеря времени. Контракт позволяет командам двигаться независимо.

Бэкенд ↔ Бэкенд

Аналогично фронту: каждый день ребейз от общей ветки, короткие фича-ветки, MR как можно скорее.

Что раньше: ревью или тесты

Однозначный ответ: сначала тесты (CI), потом ревью.

Логика простая

Ревьюер не должен тратить время на то, что автоматика проверит быстрее и точнее. Если CI падает — MR даже не смотрят. Это сохраняет время всем.

Типичная очерёдность

1. Автор открывает MR
2. CI запускается автоматически:
   - линтер
   - юнит-тесты
   - интеграционные тесты
   - сборка
3. Если CI зелёный → назначается ревьюер
4. Ревьюер смотрит код
5. После апрува → мёрж

Некоторые команды добавляют автоматические проверки безопасности (например, Snyk, Dependabot) и проверку покрытия тестами. Всё это до ревью.

Про тесты в самом коде

Есть мнение, что тесты нужно писать в том же MR, что и фичу. Не «потом допишу», а вместе. Это:

Вынуждает думать о коде с точки зрения тестируемости.
Ревьюер видит полную картину: и логику, и то, как она тестируется.
Не копится технический долг.

Сколько может висеть MR без проверки

Это один из самых болезненных вопросов командной работы.

Общепринятые нормы

Размер команды	Максимальное время ожидания
Маленькая (2–5 чел.)	4–8 часов
Средняя (5–15 чел.)	24 часа
Большая (15+ чел.)	48 часов

Если MR висит больше 2 рабочих дней — это уже проблема процесса, а не конкретного человека.

Как это решают на практике

SLA на ревью — команда договаривается: «любой MR проверяется в течение 24 часов». Это явное соглашение, а не надежда.
Ротация ревьюеров — не один senior смотрит всё, а ответственность распределена.
Напоминания — через день без ревью автор пингует в чате. Это нормально и принято.
Парное ревью — если задача сложная, двое смотрят одновременно, это ускоряет процесс.

Когда ветка становится проблемой

Долгоживущая ветка (больше 2 недель) — это красный флаг:

Она всё сильнее расходится с develop.
Мёрж будет болезненным.
Контекст у автора теряется.

Если задача большая — её разбивают на несколько MR, каждый из которых можно мёржить независимо.

Фича-флаги: скрытие и постепенный выкат

Фича-флаг (feature flag, feature toggle) — это механизм, который позволяет выкатить код в продакшн, но не включать функциональность для пользователей.

Зачем это нужно

Скрыть незаконченную фичу — код уже в проде, но пользователи её не видят.
A/B тестирование — показать фичу 10% пользователей и посмотреть на метрики.
Постепенный выкат — сначала внутренние пользователи, потом бета, потом все.
Быстрый откат — если что-то пошло не так, флаг выключается за секунды, без деплоя.

Как это выглядит в коде

// Простой пример
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckout />;
}
return <OldCheckout />;

# Бэкенд
if feature_flags.is_enabled('new_recommendation_engine', user_id=user.id):
    recommendations = new_engine.get(user)
else:
    recommendations = old_engine.get(user)

Важное правило

Фича-флаги — временные. Их нужно удалять, когда фича стабильно работает для всех. Иначе код превращается в нагромождение условий, которое никто не решается трогать.

Общая схема процесса

main (production)
  └── develop (integration)
        ├── feature/user-auth        ← Иван
        ├── feature/payment-redesign ← Мария
        └── fix/cart-bug             ← Алексей

Цикл работы:
  1. Взял задачу → создал ветку от develop
  2. Написал код + тесты
  3. Открыл MR → CI запустился автоматом
  4. CI зелёный → попросил ревью
  5. Ревьюер смотрит → комментарии → правки
  6. Апрув → мёрж в develop
  7. Develop периодически мёржится в main → деплой

Коротко о главном

Ветки короткие, MR маленькие — жизнь проще.
Ребейзиться от общей ветки каждый день — это гигиена, не опция.
CI проходит до ревью — ревьюер смотрит код, а не ищет синтаксические ошибки.
MR без ревью больше 24–48 часов — сигнал, что процесс надо чинить.
Фича-флаги дают гибкость при выкате, но требуют дисциплины в удалении.
Контракт API между фронтом и бэком позволяет работать параллельно без блокировок.

Хороший командный процесс — это не набор правил ради правил. Это соглашения, которые снижают трение и позволяют людям фокусироваться на задачах, а не на разборе конфликтов в мёрже.