Налаштування 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
# Завершення функції (merge в 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: деплой відбувається при кожному merge в 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 — мінімум один approv від іншого розробника
- Require status checks to pass — CI повинен пройти
- Require branches to be up to date — гілка повинна бути актуальна перед merge
- 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 день.