Какие бывают ветки в Git?

Типы веток в Git и их использование

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

Основные типы веток

1. Main/Master ветка

Это главная, production-ready ветка. Здесь только стабильный, проверенный код.

# Никогда не коммитишь напрямую в main
git checkout main
git pull origin main

# Создаешь feature ветку от main
git checkout -b feature/button-component

Правило: только через code review и pull requests, никогда не push напрямую.

2. Feature ветки

Ветки для разработки новых фич. Обычно имеют префикс feature/ или feat/.

# Создание feature ветки
git checkout -b feature/user-auth
git checkout -b feature/improve-search

# Работа в ветке
git add src/auth.ts
git commit -m "Add JWT authentication"
git push origin feature/user-auth

После завершения - pull request в main, code review, merge.

3. Bugfix ветки

Для исправления багов. Префикс bugfix/ или fix/.

# Исправление критического бага
git checkout -b bugfix/login-crash

# После тестирования - pull request и merge
git push origin bugfix/login-crash

4. Hotfix ветки

Для критических исправлений прямо на production. Создаются от main и сливаются обратно.

# Критический баг в production
git checkout main
git pull origin main
git checkout -b hotfix/security-vulnerability

# После исправления
git add src/security.ts
git commit -m "Fix critical security issue"
git push origin hotfix/security-vulnerability

# Pull request в main и develop (если используешь)

5. Release ветки

Для подготовки к релизу. Prefix release/.

# Создание release ветки для версии 2.0.0
git checkout -b release/2.0.0

# На этой ветке только баги и подготовка к релизу
git add package.json
git commit -m "Bump version to 2.0.0"

# После готовности - merge в main с tag
git checkout main
git merge release/2.0.0
git tag v2.0.0

Git Flow vs GitHub Flow

Git Flow - сложный workflow

* main (production)
  * release/1.2.0
  * hotfix/security-fix
* develop (staging)
  * feature/new-feature
  * bugfix/some-bug

Git Flow используют большие команды с четким release cycle.

GitHub Flow - простой workflow

* main
  * feature/something
  * bugfix/something

GitHub Flow используют более гибкие команды с частыми деплоями.

Практический пример GitHub Flow

# 1. Создаешь ветку
git checkout main
git pull origin main
git checkout -b feature/dark-mode

# 2. Делаешь работу
git add src/theme.tsx
git commit -m "Add dark mode toggle"

# 3. Pushишь
git push origin feature/dark-mode

# 4. Создаешь pull request на GitHub
# Коллеги делают review

# 5. Merge и delete
git checkout main
git pull origin main
git merge feature/dark-mode
git push origin main
git branch -d feature/dark-mode
git push origin --delete feature/dark-mode

Правила именования веток

# Хорошо
feature/add-user-profile
bugfix/fix-header-alignment
hotfix/prevent-crash-on-error
release/1.2.0

# Плохо
feature
f1
quick-fix
IMPORTANT

# Используй kebab-case, не camelCase или snake_case
feature/userProfile  # неправильно
feature/user_profile # неправильно
feature/user-profile # правильно

Удаление веток

# Удалить локальную ветку
git branch -d feature/completed

# Удалить с сервера
git push origin --delete feature/completed

# Очистить все удаленные ветки которых больше нет на сервере
git fetch --prune

Мой совет

• Используй простой GitHub Flow в большинстве случаев
• Каждой ветке - одна задача, один PR
• Удаляй ветку сразу после merge
• Синхронизируйся с main перед созданием ветки
• Не комментируй напрямую в main или develop

В modern frontend разработке GitHub Flow стал стандартом потому что он просто, быстро и хорошо работает с CI/CD пайплайнами.