29.12.2020 13:28
itglobalcom 3 4200 Источник
Если каждый член команды будет создавать ветки в 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, услуги ИБ для бизнеса: