Как устроен git workflow в команде

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

Работал ли кандидат в команде с ревью и регулярными релизами, понимает ли связь схемы ветвления с частотой поставки. Пересказ Git Flow по учебнику без объяснения, зачем такая схема, засчитывается плохо.

Как отвечать

Назвать схему, которая реально была, и причину выбора.

• Trunk-based: короткоживущие ветки на день-два, всё вливается в main, незаконченное прячется за фича-флагами. Требует быстрого CI и приличного покрытия тестами, зато даёт релиз несколько раз в день.
• GitHub Flow: ветка на задачу, PR, ревью, слияние в main, деплой с main. Стандарт для сервисов с непрерывной поставкой.
• Git Flow: main, develop, feature/*, release/*, hotfix/*. Оправдан там, где есть версионируемые релизы и поддержка нескольких версий одновременно: коробочный продукт, мобильное приложение с ревью в сторе. Для веб-сервиса с ежедневным деплоем это лишняя бюрократия, о чём написал и сам автор схемы.

Что описывать в процессе:

• ветка от свежего main, имя с номером задачи;
• перед пушем локально прогоняется тот же набор, что в CI. В Python-проекте это обычно ruff, mypy, pytest, часто под pre-commit;
• PR небольшой, до нескольких сотен строк диффа: крупные ревьюят формально и пропускают ошибки;
• защита ветки: зелёный CI и минимум один аппрув, прямой пуш в main запрещён;
• актуализация ветки: git rebase main пока ветка личная, git merge main если от неё уже кто-то ответвился. Переписывать историю опубликованной общей ветки нельзя, иначе у коллег разъедется база;
• стратегия слияния: squash даёт линейную историю по одной задаче, merge-commit сохраняет промежуточные шаги. Важно, чтобы она была одна на весь репозиторий;
• формат сообщений по договорённости, часто Conventional Commits, потому что из них генерируется changelog и вычисляется следующая версия.

Релизы: тег на коммит в main, артефакт собирается из тега, хотфикс ветвится от тега и обязательно вливается обратно в main, иначе исправление потеряется в следующем релизе.

Конфликты разрешает автор ветки, а не ревьюер. Регулярные тяжёлые конфликты это симптом слишком долгой ветки, а не проблема Git.

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

Пересказывают Git Flow как единственно верную схему, хотя работали в репозитории с двумя ветками. Второе: путают последствия rebase и merge и не могут объяснить, почему нельзя ребейзить ветку, от которой уже кто-то ответвился.