Назад к вопросам
Middle
72
questionbank

Чем отличаются подходы Trunk-Based Development и Feature Branching?

Sobes Copilot

Получайте ответы в реальном времени

Ответ от нейросети

sobes.tech AI

Критерий Trunk-Based Development (TBD) Feature Branching (FB)
Основное ветвление Одна главная ветка (trunk/main/master) Несколько долгоживущих веток (develop, release, master)
Частота слияний Очень частые (минимум раз в день) Редкие (после завершения фичи)
Размер фич-веток Очень короткоживущие (от нескольких минут до часов) Долгоживущие (от дней до недель)
Интеграция Непрерывная интеграция (CI) является ключевой Интеграция происходит реже, может быть сложнее
Риск конфликтов Меньше крупных конфликтов, но больше мелких, частых Больше крупных конфликтов при слиянии больших веток
Время выхода на прод Быстрый и частый выпуск (continuous delivery) Более медленный и редкий выпуск
Требования к тестам Высокий уровень автоматизации тестирования Тесты могут выполняться позже в цикле
Размер команды Лучше подходит для небольших и средних команд, но масштабируется с дисциплиной Хорошо подходит для больших команд

Trunk-Based Development:

  • Фокус на частую интеграцию небольших изменений напрямую в основную ветку.
  • Требует строгой дисциплины, автоматизированных тестов и фича-флагов для управления выпуском незавершенных фич.
  • Уменьшает риски, связанные с большими слияниями.

Feature Branching:

  • Каждая фича разрабатывается в отдельной ветке.
  • Слияние происходит только после завершения фичи.
  • Может приводить к "утоплению" изменений и сложным конфликтам при слиянии, если ветки живут долго.

Пример кода для TBD (упрощенно):

// Разработка ведется напрямую в main/trunk
public class FeatureA {
    public void doStuff() {
        // Код фичи А
    }
}

// Другой разработчик коммитит в main/trunk почти одновременно
public class FeatureB {
    public void doOtherStuff() {
        // Код фичи B
    }
}

Пример кода для FB (упрощенно):

// Разработчик 1 работает в ветке feature/A
// git checkout -b feature/A develop
public class FeatureA {
    public void doStuff() {
        // Код фичи A
    }
}

// Разработчик 2 работает в ветке feature/B
// git checkout -b feature/B develop
public class FeatureB {
    public void doOtherStuff() {
        // Код фичи B
    }
}

// После завершения фичи А, ветка мержится в develop
// git checkout develop
// git merge feature/A

// После завершения фичи B, ветка мержится в develop
// git checkout develop
// git merge feature/B // Возможны конфликты с кодом из feature/A