Бранч-стратегии при разработке в Git
Если каждый член команды будет создавать ветки в Git так, как хочет, это обязательно приведет к хаосу и несогласованности. Чтобы избежать этого, лучше сформулировать и принять соответствующую бранч-стратегию — так вы сможете больше времени уделять разработке, а не управлению версиями. Нужно принять тот факт, что стратегия ветвления — важный рабочий инструмент.
Три подхода
Вы можете использовать одну из этих популярных методик или же взять их как основу для создания своей.
GitHub Flow. Стратегией пользуются в команде сервиса GitHub. Главные требования звучат так:
- в коде в мастер-ветке не допускаются ошибки, и он должен быть готов к развертыванию в любой момент;
- чтобы начать разрабатывать новую функцию, необходимо создать feature-ветку в master-ветке и дать ей очевидное для всех имя. Когда работа будет готова, ее нужно смерджить в master-ветку через pull request;
- после мерджа изменений их нужно сразу же развернуть на сервере.
Этот подход обычно используют для продуктов с одной версией, которая обновляется не очень часто. Например, веб-сайтов. Из плюсов — разработчикам при таком подходе проще понимать и организовывать свою работу. Главный минус — если ваш проект достаточно сложный и обновляется часто, лучше использовать другую стратегию.
GitFlow. Сразу стоит сказать, что эта стратегия дискуссионная. О ней есть много как положительных, так и отрицательных отзывов.
Суть в следующем. Есть два типа постоянных веток: master-ветка, чтобы понимать, как выглядит последняя актуальная версия, и development-ветка, где ведется разработка. От нее идут три вида временных веток.
- Feature, для добавления новых возможностей. После завершения работы нужно создать pull request в development-ветку.
- Release, для работы над новыми версиями. Важно добавить в название номер версии, это поможет не запутаться и отследить изменения.
- Hotfix, для быстрого исправления багов.
Этот подход считается одним из оптимальных для проектов, где постоянно разрабатывается несколько версий для разных платформ.
В 2010 году вышел текст голландского программиста Винсента Дриссена «A successful Git branching model», в которой он впервые рассказал о GitFlow. Статья стала довольно популярной, появился русский перевод, а методика была взята на вооружение во многих командах.
В 2020 году американский программист Джордж Стокер выпустил статью «Please stop recommending Git Flow», где он раскритиковал метод, как устаревший и неэффективный в современных реалиях. Дриссен в ответ дополнил свой текст 2010 года дисклеймером, в котором признал, что его метод не панацея, а только один из вариантов организации работы.
Forking Workflow. Здесь подход такой: существует оригинальный репозиторий для мерджа всех изменений и его копия, в которой работает другой разработчик. Подход очень близок к идеологии open source, его цель — использовать все преимущества open-source-сообщества в рамках проекта. При этом большая часть рабочего процесса в части ветвления копирует GitFlow. Feature-ветки здесь будут мерджиться с локальными репозиториями разработчиков. Таким образом, разработка становится гибкой даже для очень больших команд с подрядчиками.
Среди тех, кто использует такой подход — Linux. Вы можете предложить свои варианты изменения кода даже для ядра системы. И этот подход, судя по всему, эффективно работает.
Общие моменты
Какую бы концепцию вы не выбрали, есть основные моменты, которых лучше придерживаться. Вот, например, правила Microsoft:
- не усложняйте вашу бранч-стратегию;
- используйте feature-ветки для всех обновлений и исправления ошибок;
- объединяйте feature-ветки в основные с помощью pull requests;
- поддерживайте высокое качество и актуальность основной ветки.
Стратегия, основанная на этих идеях приведет к тому, что ваша команда будет работать с логичными и простыми для понимания версиями.
Вот еще несколько полезных принципов.
Называйте все просто и очевидно
Это поможет всем членам команды правильно понимать, кто над чем работает. Также допустимо включить в название ветки дополнительную информацию, например, имя создателя. Это тот случай, когда не нужно придумывать что-то оригинальное. Названия веток типа «пользователи», «багфикс», «feature», «hotfix» — то что надо. Для веток, работа в которых затягивается, используйте отдельные специальные флаги. Это позволит команде сразу понимать о чем идет речь и всегда держать в голове эти задачи как долгосрочные.
Слияние веток только через pull request
Механизм pull request зарекомендовал себя как логичный и хорошо придуманный. Так как этот процесс требует времени, вы должны принять внутри команды, что и в какие сроки ожидается от всех участников pull request. Распределите обязанности ревьюеров и расскажите об этом команде через внутреннюю базу знаний.
Вот немного конкретных советов:
- согласно исследованию Microsoft, оптимальное число ревьюеров — двое;
- если в вашей команде уже сформировались принципы рецензирования кода, придерживайтесь их и старайтесь не ломать;
- pull request работает намного лучше, когда обязанность ревьюить код регулярно возникает у большего числа членов команды;
- оставляйте достаточно подробные описания к своей работе, чтобы ревьюеры могли быстро понять контекст.
Настройте branch policies
Потратить время на политики ветвления стоит по нескольким причинам:
- так вы сможете изолировать текущую работу от завершенной в рамках главной ветки;
- внесете разумные ограничения, определив кто и какие изменения может вносить в конкретные ветки;
- быстро распространите эффективные методы работы.
Два основных правила, исходя из которых следует настраивать политики:
- ревьюеры в pull request добавляются автоматически, в момент его создания. Вы можете сначала определить их список, а затем редактировать по ходу работы;
- для выполнения pull request требуется успешная сборка. Код, влитый в основную ветку, должен собираться чисто.
Но самый главный принцип при создании своей бранч-стратегии такой: нужно продумать ее так, чтобы у команды не возникало вопросов по поводу смысла того или иного действия. Тогда в вашем проекте каждый день будет результативным.
Блог ITGLOBAL.COM — Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:
