Как устроена работа с Git, ветками, ревью и процессом релиза

Что проверяют

Работали ли вы в команде с внятным процессом доставки кода и понимаете ли, зачем нужно каждое звено. Следом спрашивают: merge или rebase, как откатить неудачный релиз фронтенда и что проверяет CI до ревью.

Как отвечать

• модель ветвления: trunk-based с короткоживущими ветками от main сейчас встречается чаще, чем Git Flow с develop и release/*. Git Flow оправдан, когда поддерживается несколько версий сразу, например у библиотеки. Веб-приложению с частыми выкатками он обычно лишний;
• перед ревью: ветка обновляется от main, CI прогоняет eslint, проверку типов tsc --noEmit, юнит-тесты и сборку. Для фронтенда полезно превью-окружение на каждый PR, чтобы ревьюер и дизайнер смотрели живую страницу;
• ревью: небольшой PR с описанием и скриншотами до и после. Ревьюер смотрит логику, доступность, лишние перерисовки и рост бандла, а форматирование оставляет Prettier;
• слияние: squash merge даёт одну запись на задачу в истории main, обычный merge сохраняет коммиты ветки. Выбор закрепляется настройкой репозитория, как и запрет прямого пуша в main;
• релиз: тег по семверу (git tag -a v2.3.0), changelog, часто собранный по Conventional Commits, сборка и выкладка из CI. Откат делается повторной выкладкой предыдущего артефакта или git revert, а незаконченные фичи прячутся за фича-флагами, а не живут в долгой ветке.

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

Где спотыкаются

Делают git push --force в общую ветку после rebase. Переписывать можно только свою ветку, и лучше через --force-with-lease.

Присылают PR на две тысячи строк, где рефакторинг смешан с фичей. Такой код ревьюят по диагонали, и баги проходят.

Считают релизом слияние в main. Без тега, артефакта и понятного отката это просто коммит, и при инциденте непонятно, что именно сейчас на проде.