Ветку для задачи создаешь от ветки develop или master

От какой ветки создавать ветку для задачи: develop или master

Этот вопрос касается git workflow и зависит от используемой модели разработки. Существует несколько основных подходов, и правильный ответ зависит от выбранной стратегии в проекте.

Git Flow модель

Git Flow — классическая модель, разработанная Vincent Driessen. Здесь используется несколько основных веток:

master (production)
  |
  +-- release/ (подготовка релиза)
  |
 develop (интеграционная ветка)
  |
  +-- feature/... (новые фичи)
  +-- bugfix/... (исправления багов)
  +-- hotfix/... (срочные исправления для продакшена)

В Git Flow ты создаёшь новую ветку ОТ develop:

# Сначала синхронизируешься
git checkout develop
git pull origin develop

# Создаёшь новую ветку для задачи
git checkout -b feature/auth-component
# или
git checkout -b bugfix/login-validation

Почему от develop?

• develop содержит последние разработки
• master содержит только готовый, протестированный код для production
• Когда фича готова, её merge-ят в develop для интеграции
• Когда готов новый релиз, develop merge-ят в master и создают тег

GitHub Flow модель

GitHub Flow — упрощённая модель, популярная в modern startups:

main (production)
  |
  +-- feature/... (новые фичи)
  +-- bugfix/... (исправления)
  +-- docs/... (документация)

В GitHub Flow ты создаёшь новую ветку ОТ main (master):

# Сначала синхронизируешься
git checkout main
git pull origin main

# Создаёшь новую ветку для задачи
git checkout -b feature/auth-component

Почему от main?

• main всегда готов к деплою (или почти готов)
• Каждая фича создаётся отдельной веткой
• Кода готова — делаешь pull request
• После code review и тестов merge-ят в main
• main автоматически deploy-ится

Trunk-Based Development

Trunk-Based Development — новый тренд, используется в FAANG компаниях:

main (единственная основная ветка)
  |
  +-- feature/... (короткоживущие ветки, 1-2 дня)

В TBD ты создаёшь новую ветку ОТ main:

git checkout main
git pull origin main

# Короткоживущая ветка
git checkout -b feature/small-button-fix

Характеристики:

• Очень частые small commits в main
• Ветки живут максимум 1-2 дня
• Continuous integration и feature flags

Сравнение моделей

Что выбрать в вашем проекте?

Создавай ветку от develop, если:

• Проект использует Git Flow
• Есть выделенный릴 process и release цикл
• Несколько сред (dev, staging, production)
• Большая команда с разделением ролей
• Legacy проект

Создавай ветку от main/master, если:

• Проект использует GitHub Flow
• Быстрый цикл разработки (несколько релизов в день)
• Lean/agile процесс
• main всегда готов к деплою
• CI/CD настроен хорошо

Пример: как узнать текущую модель проекта?

# Посмотри ветки
git branch -a

# Если видишь:
# - develop (интеграционная ветка)
# - feature/*, bugfix/*, release/*, hotfix/* ветки
# -> Это Git Flow, создавай от develop

# Если видишь:
# - main (единственная основная ветка)
# - feature/*, docs/* ветки
# -> Это GitHub Flow, создавай от main

# Посмотри конфиг проекта
cat .github/workflows/ci.yml  # CI/CD конфиг
cat README.md                  # Документация по процессу

Практические примеры

Пример 1: Git Flow в enterprise проекте

# Текущее состояние
git branch -a
# master
# develop
# feature/user-auth
# release/1.2.0

# Создаёшь новую фичу
git checkout develop  # От develop!
git pull origin develop
git checkout -b feature/user-profile

# Работаешь...
git add .
git commit -m "Add user profile component"
git push origin feature/user-profile

# Открываешь PR develop <- feature/user-profile
# После code review и тестов merge-ят в develop
# Когда готов релиз, делают release-ветку и merge в master

Пример 2: GitHub Flow в startup проекте

# Текущее состояние
git branch -a
# main
# feature/dark-mode
# feature/api-optimization

# Создаёшь новую фичу
git checkout main  # От main!
git pull origin main
git checkout -b feature/notifications

# Работаешь...
git add .
git commit -m "Add notification system"
git push origin feature/notifications

# Открываешь PR main <- feature/notifications
# После code review merge-ят в main
# main автоматически deploy-ится на production

Пример 3: Trunk-Based Development в FAANG

# Очень часто commit-ы в main
git checkout main
git pull origin main

# Супер короткая ветка
git checkout -b feature/fix-button-padding

# Минимальные изменения
git add .
git commit -m "Fix button padding"
git push origin feature/fix-button-padding

# Почти сразу merge в main (или через 1-2 часа после code review)
# Если полностью готово — включаешь через feature flag

Важные моменты

1. Всегда синхронизируйся перед созданием ветки

# Убедись, что локальная ветка актуальна
git checkout develop  # или main
git pull origin develop

2. Никогда не создавай ветку из старой ветки

# ✗ Неправильно
git checkout feature/old-feature  # Старая ветка
git checkout -b feature/new-feature  # Ветка тоже устаревшая

# ✓ Правильно
git checkout develop  # Свежая ветка
git pull origin develop
git checkout -b feature/new-feature

3. Используй правильные префиксы

# feature/ — новая функциональность
git checkout -b feature/user-authentication

# bugfix/ — исправление бага
git checkout -b bugfix/login-validation

# hotfix/ — срочное исправление для production
git checkout -b hotfix/payment-issue

# docs/ — только документация
git checkout -b docs/readme-update

# refactor/ — переработка кода без новой функциональности
git checkout -b refactor/component-structure

Заключение

Ответ зависит от git workflow вашего проекта:

• Git Flow -> создавай от develop
• GitHub Flow -> создавай от main или master
• Trunk-Based Development -> создавай от main или master

Уточни у своего lead-а или посмотри в README проекта, какая модель используется. В 2024 году большинство modern проектов используют GitHub Flow или TBD, поэтому чаще всего правильный ответ — от main/master.