Особенность, расширяющая ваш путь к величию
Или задача, переходящая ваш путь туда. Или релиз ветвления. На ваш выбор.
Сегодня почти все системы контроля версий поддерживают независимые от ветвей направления работы, основанные на одной центральной кодовой базе. В зависимости от вашей системы контроля версий, основная ветвь может называться главной, основной, стандартной или внешней. Разработчики могут создавать свои собственные ветви из основной строки кода и работать независимо друг от друга.
Зачем беспокоиться о ветвлении?
Ветвление позволяет командам разработчиков легко сотрудничать внутри одной центральной базы кода. Когда разработчик создает ветку, система управления версиями создает копию базы кода в этот момент времени. Изменения в ветке не влияют на других разработчиков в команде. Это хорошая вещь, очевидно, потому что разрабатываемые функции могут создавать нестабильность, которая будет очень разрушительной, если вся работа будет происходить в основной строке кода. Но ветви не должны жить в одиночном уединении. Разработчики могут легко отстранить изменения от других разработчиков для совместной работы над функциями и убедиться, что их частная ветвь не слишком отличается от основной.
PROTIP
Ветви не просто хороши для функциональной работы. Ветви могут изолировать команду от важных архитектурных изменений, таких как обновление фреймворков, общих библиотек и т. д.
Три стратегии ветвления для agile команд
Модели ветвления часто различаются между командами и являются предметом многочисленных споров в сообществе разработчиков программного обеспечения. Одна большая тема спора заключается в том, сколько работы должно остаться в ветке, прежде чем снова быть объединенной с основной.
Ветвление релиза
Ветвление релиза относится к идее, что релиз полностью содержится в пределах ветки. Это означает, что в конце цикла разработки менеджер релиза создаст ветку от основной (например, «1.1 ветка разработки»). Все изменения для версии 1.1 необходимо применить дважды: один раз к ветви 1.1, а затем к строке основного кода. Работа с двумя ветвями - это дополнительная работа для команды, и можно легко забыть объединить обе ветви. Ветви релизов могут быть громоздкими и трудными для управления, так как над одной и той же ветвью работает много людей. Мы все чувствовали тревогу от необходимости объединять множество различных изменений в одной ветви. Если вы должны сделать ветку релиза, создайте ветку как можно ближе к фактической версии.
ПРЕДУПРЕЖДЕНИЕ:
Разветвление выпусков релизов является важной частью поддержки программного обеспечения с версионным программным обеспечением на рынке. Один продукт может иметь несколько веток выпусков релиза (например, 1.1, 1.2, 2.0) для поддержки устойчивой разработки. Имейте в виду, что изменения в более ранних версиях (т. е. 1.1), возможно, потребуется объединить с более поздними ветвями релиза (т. е. 1.2, 2.0). Посетите наш вебинар ниже, чтобы узнать больше об управлении ветками выпусков релизов с помощью Git.
Ветвление функций
Ветви функций часто связаны с флагами функций - «переключателями», которые включают или отключают функцию в продукте. Это облегчает развертывание кода в основном и контроле, когда функция активирована, и позволяет легко развернуть код задолго до того, как функция будет доступна конечным пользователям.
Еще одно преимущество флагов функций заключается в том, что код может оставаться в сборке, но неактивным во время разработки. Если что-то идет не так, когда функция включена, системный администратор может вернуть флаг функции и вернуться в известное исправное состояние, а не развертывать новую сборку.
Ветвление задачи
В Atlassian мы концентрируемся на рабочем процессе ветвления на задачу. У каждой организации есть естественный способ разбить работу по отдельным задачам внутри системы отслеживания проблем, такой как программное обеспечение Jira. Задачи становятся центральным контактом команды для этой части работы. Ветвление задачи, также известное как ветвление задач, напрямую связывает эти задачи с исходным кодом. Каждая задача реализована в отдельной ветви, ключ которой включен в название ветви. Легко увидеть, какой код реализует какую задачу: просто найдите ключ задачи в имени ветви. С таким уровнем прозрачности легче применять определенные изменения к основной ветви или более поздней устаревшей ветви релиза.
Поскольку agile центры сосредоточены вокруг пользовательских историй, ветви задач хорошо сочетаются с agile разработкой. Каждая пользовательская история (или исправление бага) находится в отдельной ветке, что позволяет легко увидеть, какие проблемы находятся в процессе, а какие готовы к релизу. Для глубокого погружения в ветвление задач (иногда называемое ветвлением задачи или ветвлением на задачу), возьмите немного попкорна и посмотрите запись вебинара ниже - один из наших самых популярных за всю историю.
ВИДЕО
Теперь встречайте злого близнеца ветвления: слияние
Мы все перенесли боль, пытаясь объединить несколько ветвей в одно разумное решение. Традиционно централизованные системы контроля версий, такие как Subversion, сделали слияние очень болезненной операцией. Но более новые системы контроля версий, такие как Git и Mercurial, используют другой подход для отслеживания версий файлов, которые находятся в разных ветках.
ТВИИТ:
С Git объединение становится тривиальным, освобождая нас от использования всех возможностей ветвящихся рабочих процессов.
Ветви имеют тенденцию быть недолговечными, что облегчает их объединение и делает их более гибкими в базе кода. Между способностью часто и автоматически объединять ветви как часть непрерывной интеграции (CI) и тем фактом, что кратковременные ветви просто содержат меньше изменений, «ад слияния» становится делом прошлого для команд, использующих Git и Mercurial.
Вот что делает ветвление задач таким потрясающим!
Подтвердить, подтвердить, подтвердить
Система контроля версий может повлиять только на результат слияния. Автоматизированное тестирование и непрерывная интеграция также важны. Большинство CI (непрерывной интеграции) -серверов могут автоматически проверять новые ветви, что значительно сокращает количество «сюрпризов» после окончательного слияния в восходящем потоке и помогает поддерживать стабильность основной строки кода.
По материалам Agile Coach "Branching"