Преуспеть с помощью функциональных веток

Или с помощью веток заданий. Или веток релизов. Выбор за вами.

Dan Radigan Dan Radigan
Просмотр тем

Практически все современные системы управления версиями поддерживают ветки — независимые направления деятельности, берущие начало от одной центральной базы кода. В зависимости от того, какую систему управления версиями вы используете, основная ветка может называться главной (master), магистралью, веткой по умолчанию или стволом. Разработчики могут создавать собственные ветки, отходящие от главной ветки кода, и работать над ними параллельно с ней.

Зачем нужны ветки?

Ветки позволяют командам разработчиков без труда вести совместную работу над единой центральной базой кода. Когда разработчик создает ветку, система управления версиями создает копию базы кода, актуальную на текущий момент времени. Изменения ветки не влияют на работу других разработчиков в команде. Это, конечно же, хорошо, потому что разработка функций сопряжена с постоянными изменениями, и если бы вся работа велась в главной ветке, процесс разработки погрузился бы в хаос. Но ветки не должны существовать в полной изоляции. Разработчики могут без труда запрашивать изменения у других разработчиков, чтобы вместе работать над функциональностью и не допускать слишком сильного отклонения их собственной ветки от главной.

Профессиональный совет

Ветки нужны не только для работы над новыми функциями. Они могут оградить команду от влияния значительных архитектурных изменений, например обновления платформ, общих библиотек и т. д.

Три стратегии ветвления для agile-команд

Обычно каждая команда пользуется своей моделью ветвления. В сообществе разработчиков часто спорят о том, какой подход наиболее эффективен. Камнем преткновения в большинстве случаев является объем работы, который должен находиться в ветке перед ее слиянием с главной веткой.

Использование веток релизов

Эта стратегия предполагает, что весь релиз помещается в одну ветку. Согласно ней, на поздних этапах цикла разработки менеджер по релизам создает новую ветку, отходящую от главной (например, «ветка разработки версии 1.1). Все изменения версии 1.1 нужно применить дважды: к ветке 1.1 и затем к основной базе кода. С появлением второй ветки у команды появляется дополнительная работа. К тому же легко забыть о необходимости выполнять слияние. В некоторых случаях в ветках релизов сложно разобраться и ими сложно управлять, поскольку над одной и той же веткой работает сразу много людей. Мы все проходили через мучения, которые вызывает необходимость объединять множество различных изменений в одной ветке. Если вам нужна ветка релиза, создавайте ее как можно ближе к дате фактического выпуска новой версии.

Предупреждение

Ветки релизов играют важную роль для поддержки ПО, представленного на рынке сразу несколькими версиями. У одного продукта может быть несколько веток релизов (например, 1.1, 1.2, 2.0), на базе которых ведется длительная разработка. Помните, что изменения в более ранних версиях (таких как 1.1), возможно, понадобится объединить с ветками более поздних релизов (таких как 1.2, 2.0). Подробнее об управлении ветками релизов с помощью Git можно узнать из вебинара, запись которого приведена ниже.

Использование функциональных веток

Часто функциональные ветки снабжаются флагами возможностей — «переключателями», с помощью которых можно включить или отключить возможность в составе продукта. Благодаря этому проще развертывать код в главной ветке и выбирать, когда активировать новую функцию. В итоге первоначальное развертывание кода может произойти задолго до демонстрации функции конечным пользователям.

Подсказка

Использовать флаги возможностей полезно и потому, что код остается в сборке, но не активен, пока идет разработка. Если при активации возникнут проблемы, флаг возможности позволяет системному администратору выключить ее и вернуться к заведомо исправному состоянию, вместо того чтобы развертывать новую сборку.

Использование веток заданий

В компании Atlassian преимущественно используют модель, согласно которой для каждого задания создается по ветке. В каждой организации принято по-своему делить объем работы на отдельные задания в трекере задач, таком как Jira Software. Задачи становятся главными точками соприкосновения с тем или иным заданием для команды. При использовании веток заданий (задач), устанавливается прямая связь между задачами и исходным кодом. Каждая задача выполняется в своей собственной ветке; к названию этой ветки добавляется ключ соответствующей задачи. По ключу задачи в названии ветки легко понять, к какой задаче относится тот или иной участок кода относится к какой задаче. Такая прозрачность позволяет без труда применять отдельные изменения к главной ветке или ветке любого предыдущего релиза, который уже давно находится в работе.

Поскольку agile вращается вокруг пользовательских историй, ветки заданий идеально вписываются в процесс agile-разработки. Каждой пользовательской истории (или исправлению бага) выделяется собственная ветка, и благодаря этому несложно понять, какие задачи еще выполняются, а какие уже готовы к релизу. Подробнее об использовании веток заданий (эта стратегия известна также как создание веток задач или модель «ветка на каждую задачу») можно узнать, просмотрев запись увлекательного вебинара ниже. Кстати, он занимает верхние строки в рейтинге популярности наших вебинаров!

А теперь познакомимся со злым братом-близнецом ветвления — слиянием

Всем нам довелось пройти через испытание по объединению нескольких веток в одно вразумительное решение. Из-за таких централизованных систем управления версиями, как Subversion, сложился стереотип о слиянии как о чем-то невероятно мучительном. Однако более новые системы управления версиями, такие как Git и Mercurial, предлагают другой подход к отслеживанию версий файлов, содержащихся в разных ветках.

Работа над ветками в большинстве случаев ведется недолго, из-за чего проще выполнять их слияние и управлять ими в разных участках базы кода. С одной стороны, непрерывная интеграция (CI) позволяет объединять ветки часто и автоматически; с другой стороны, ветки, которые меньшее время находятся в работе, попросту содержат меньше изменений. Благодаря этому для команд, использующих Git и Mercurial, «муки слияния» канули в лету.

Вот почему использовать ветки заданий так круто!

Проверка, проверка и еще раз проверка

Возможности системы управления версиями ограничиваются влиянием на исход слияния. Большое значение имеют автоматическое тестирование и непрерывная интеграция. Большинство серверов CI могут автоматически подвергать новые ветки тестам, благодаря чему вероятность столкнуться с ошибками при заключительном слиянии с вышестоящей веткой значительно снижается, и главная ветка кода остается стабильной.

продолжение темы
Git branching video