Как было организовано ветвление на предыдущем месте работы?

Как было организовано ветвление на предыдущем месте работы?

На моих предыдущих проектах я работал с разными моделями ветвления, и каждая имела свои преимущества и недостатки. Расскажу про самую успешную стратегию, которую я применял.

Git Flow (классическая модель)

На одном из крупных проектов мы использовали Git Flow — полноценную модель управления ветками для синхронизации разработки и релизов.

Структура ветвей

main (production)
  ↑
  |-- release branches (v1.2.0)
  |      ↑
      develop (staging)
        ↑
        |-- feature branches
        |   ├── feature/user-auth
        |   ├── feature/comments
        |   └── feature/dark-mode
        |
        |-- bugfix branches
            ├── bugfix/login-error
            └── bugfix/email-validation

Главные ветви:

1. main — production готовый код

   • Только для merge-ов из release ветвей
   • Каждый коммит = новая версия
   • Защищена от прямых push'ей

2. develop — staging, основная разработка

   • Сюда мержатся feature ветви
   • Здесь тестируют интеграцию
   • Должна быть стабильной

Рабочие ветви:

1. feature/* — новые функции

   • Создаём из develop
   • Мержим обратно в develop через PR
   • Удаляем после merge

2. bugfix/* — срочные фиксы в develop

   • Аналогично feature

3. release/* — подготовка к релизу

   • Создаём из develop когда готов релиз
   • Фиксим только баги (не новые фичи)
   • Мержим в main и develop

4. hotfix/* — срочные фиксы в production

   • Создаём из main
   • Мержим в main и develop

Пример рабочего процесса

# 1. Начинаем новую фичу
git checkout -b feature/dark-mode develop

# 2. Работаем, коммитим
git add .
git commit -m "Add dark theme provider"
git commit -m "Add theme toggle component"

# 3. Пушим
git push origin feature/dark-mode

# 4. Открываем PR в develop
# -> Code review
# -> CI/CD тесты
# -> Approval

# 5. Merge в develop
git checkout develop
git pull origin develop
git merge --no-ff feature/dark-mode  # --no-ff создаёт merge commit

# 6. Удаляем ветку
git push origin :feature/dark-mode
git branch -d feature/dark-mode

Trunk-Based Development (TBD)

На другом проекте мы использовали Trunk-Based Development — более современный подход, особенно для fast-moving teams.

Структура

main (production + development)
  ↑
  |-- feature branches (короткоживущие)
  |   ├── dark-mode (1-2 дня)
  |   ├── api-migration (1-2 дня)
  |   └── ui-redesign (1-2 дня)
  |
  |-- tags
      ├── v1.2.0 (릴리즈)
      └── v1.1.5

Принципы:

1. Одна главная ветка — main
2. Короткоживущие feature ветви — 1-2 дня максимум
3. Много маленьких merge'ей — вместо редких больших
4. Быстрый CI/CD — код попадает в main быстро
5. Feature flags — контролируем, какие фичи видны

Рабочий процесс

# 1. Синхронизируемся с main
git checkout main
git pull origin main

# 2. Создаём short-lived ветку (максимум 1-2 дня)
git checkout -b feat/dark-mode

# 3. Часто коммитим и пушим
git add .
git commit -m "Add theme context"
git push origin feat/dark-mode

# 4. Открываем PR (часто несколько в день)
# -> Быстрый review (максимум 1 час)
# -> CI пройден
# -> Merge

# 5. Сразу попадает в production (или staging если есть feature flag)

Feature flags для контроля:

// Фича видна только для beta-тестеров
if (featureFlags.isDarkModeEnabled) {
  return <DarkModeProvider>{children}</DarkModeProvider>;
}

// Или для определённых пользователей
if (user.isBetaTester && featureFlags.isDarkMode) {
  return <DarkTheme />;
}

Нужно ли было выбирать между ними?

Git Flow — когда:

• Есть четкие релиз циклы (v1.0 -> v1.1 -> v1.2)
• Нужна стабильная staging среда
• Команда более чем 10 человек
• Проект находится на production (нельзя ломать)

TBD — когда:

• Часто деплоим (несколько раз в день)
• Используем feature flags
• Небольшая команда (< 10)
• Быстрый CI/CD

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

Пример 1: Git Flow на проекте с релизами

# Подготовка к релизу v1.2.0
git checkout -b release/1.2.0 develop

# Фиксим баги в release ветке
git commit -m "Fix: memory leak in dark mode"
git commit -m "Fix: typo in settings"

# Мержим в main
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"

# Мержим обратно в develop (важно!)
git checkout develop
git merge --no-ff release/1.2.0

# Удаляем release ветку
git branch -d release/1.2.0

# Deploy в production
./deploy.sh v1.2.0

Пример 2: TBD с feature flags

// features.config.ts
export const featureFlags = {
  darkMode: process.env.DARK_MODE_ENABLED === 'true',
  newUI: process.env.NEW_UI_ENABLED === 'true',
  betaFeatures: process.env.BETA_FEATURES === 'true'
};

// components/ThemeProvider.tsx
function ThemeProvider({ children }) {
  if (!featureFlags.darkMode) {
    return <>{children}</>;
  }
  
  return (
    <DarkModeProvider>
      {children}
    </DarkModeProvider>
  );
}

# Feature flag может меняться без кода
DARK_MODE_ENABLED=true npm run deploy

# Или включаем только для конкретного пользователя
user.betaFlags.includes('dark-mode') && enableDarkMode()

Какую модель я предпочитаю?

Для большинства modern проектов я выбираю Trunk-Based Development потому что:

1. Меньше конфликтов — ветки живут 1-2 дня
2. Быстрее интеграция — код в main каждый день
3. Проще отладка — меньше расхождений
4. Лучше для CI/CD — часто деплоим
5. Масштабируется — растёт с командой

Но Git Flow нужен когда:

• Есть длинные разработки (3+ месяца)
• Нужна стабильная staging среда
• Несколько параллельных релизов

Правила, которые я применял везде

# 1. Никогда не мержим прямо в main
# ❌ git checkout main && git merge feature
# ✅ Только через PR с review

# 2. Всегда используем --no-ff для merge commits
# ✅ git merge --no-ff feature-branch
# (Сохраняет историю ветки)

# 3. Удаляем ветку после merge
# ✅ git push origin :branch-name

# 4. Переуходим из главной ветки
# ✅ git pull origin main перед работой

# 5. Маленькие, понятные ветки
# ✅ feature/dark-mode (1-2 дня)
# ❌ dev-everything (2+ месяца)

# 6. Осмысленные commit messages
# ✅ "Add dark mode toggle component"
# ❌ "Fix stuff", "Updates", "Lol"

Инструменты для управления ветвлением

# Посмотреть все ветки и их статус
git branch -a

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

# Удалить ветку на remote
git push origin :branch-name

# Переименовать ветку
git branch -m old-name new-name

# Посмотреть где ветка в разработке
git log --graph --oneline --all

# Очистить старые ветки
git remote prune origin

Выводы

Из опыта работы я научился:

1. Выбирай модель под проект — не один размер подходит всем
2. Главное — консистентность — команда должна следовать одному подходу
3. Защищай главные ветки — никаких прямых push'ей в main
4. Code review обязателен — даже для опытных разработчиков
5. Удаляй старые ветки — чистота репозитория важна
6. Автоматизируй проверки — CI должен проверять каждый PR
7. Документируй — напиши процесс для новых членов команды

Правильное ветвление — это база хорошей командной разработки. Один неправильный merge может сломать проект на несколько часов, поэтому это всерьез.