Почему большинство команд страдают от хаоса в git

Знаете, почему большинство команд страдают от хаоса в Git? Потому что каждый делает ветки как хочет. Кто-то пушит прямо в master, кто-то создаёт ветку на каждую задачу и забывает её мержить месяцами.

В 2010 году голландский разработчик Vincent Driessen написал статью, которая изменила подход к ветвлению для тысяч команд. Её до сих пор цитируют, хотя Git Flow (так назвали эту модель) успели и возненавидеть, и полюбить.

Суть проста: есть два основных потока разработки и три типа вспомогательных веток.

GIT BRANCHING MODEL
══════════════════════════════════════════════════════
                                                    
  master ────●────●────●────●────●─── (release)      
       \     \                    /                  
        \     `--●──●──●──●──●───'                  
        \                                            
  develop ──●────●────●────●────●────●───           
       │    │                               │        
       │    ├── feature/login ──────────►──┘        
       │    ├── feature/cart ────────────►          
       │    └── feature/checkout ───────►           
       │                                           
       └──── hotfix/critical ──────────────────►   
                                                    
══════════════════════════════════════════════════════

Разбираем по частям:

• master — священная ветка. Только релизный код, только теги с версиями.
• develop — основная рабочая ветка. Здесь всё сливается перед релизом.
• feature/* — короткоживущие ветки для фич. Создаём от develop, мержим обратно в develop.
• release/* — когда develop готов к релизу, создаём ветку от него. Фиксим мелкие баги, мержим в master и develop.
• hotfix/* — срочные исправления. Создаём от master, мержим в master и develop.

Звучит сложно? На практике — это просто набор правил, которые понимают все.

Для команд до 10 человек это работает отлично. Для больших — уже тяжеловато: слишком много церемоний, слишком много merge-конфликтов.

Но вот что интересно: Driessen написал эту модель для себя, для своего проекта. А она стала индустриальным стандартом. Иногда лучший способ решить проблему — просто задокументировать своё решение достаточно хорошо.

Кстати, сам Vincent Driessen уже несколько лет рекомендует использовать упрощённую версию — без отдельных release-веток. Но это уже совсем другая история.

Ссылки

• A Successful Git Branching Model — оригинальная статья Vincent Driessen