Настройка Git Flow / GitHub Flow для командной разработки сайта
Без договорённости о ветках команда из 3+ человек неизбежно получает конфликты в main, непонятно когда деплоить и регулярные «кто сломал продакшен». Git Flow и GitHub Flow — два проверенных подхода с разными trade-off.
Git Flow: когда подходит
Git Flow имеет смысл при: редких релизах (раз в неделю или реже), необходимости поддерживать несколько версий, сложных hotfix-процессах.
Структура веток:
-
main— только production-ready код, теги версий -
develop— интеграционная ветка, откуда берутся feature-ветки -
feature/ticket-123-user-auth— разработка фичи -
release/1.5.0— подготовка релиза (bugfixes, обновление версий) -
hotfix/1.4.1-payment-fix— срочные правки в production
# Инициализация Git Flow
git flow init
# Начало фичи
git flow feature start user-authentication
# Завершение фичи (мерж в develop)
git flow feature finish user-authentication
# Создание релиза
git flow release start 1.5.0
# ... финальные правки, обновление CHANGELOG
git flow release finish 1.5.0
GitHub Flow: когда подходит
GitHub Flow проще и лучше подходит для continuous delivery: деплой происходит при каждом мерже в main.
Правила:
-
main— всегда deployable - Всё делается в ветках от
main - Называем ветки понятно:
feat/user-dashboard,fix/checkout-crash,chore/update-deps - Открываем PR для любого изменения
- Деплоим из ветки, мержим только после проверки в production
Naming conventions
Единые правила именования веток снижают когнитивную нагрузку:
feat/JIRA-123-short-description # новая функциональность
fix/JIRA-456-bug-description # исправление бага
chore/update-node-20 # технические задачи
docs/update-api-reference # документация
refactor/extract-payment-service # рефакторинг
Branch protection rules
В GitHub Settings → Branches настраиваем защиту main:
- Require pull request before merging — прямой push в main запрещён
- Require approvals: 1 — минимум один аппрув от другого разработчика
- Require status checks to pass — CI должен пройти
- Require branches to be up to date — ветка должна быть актуальна перед мержем
- Do not allow bypassing the above settings — применяется в том числе для администраторов
.gitconfig и шаблоны
Шаблон commit message для команды:
# .gitmessage
# Тип: feat, fix, docs, chore, refactor, test, perf
# feat(auth): добавить OAuth через Google
#
# Тело (опционально): что и почему, не как
#
# JIRA: PROJ-123
git config --global commit.template ~/.gitmessage
Сроки
Выбор и документирование процесса, настройка branch protection rules, шаблонов и хуков для команды — 0,5–1 день.