Ветвление в Git для agile-команд

Переходя на Git, команды разработчиков открывают для себя agile на новом уровне, и вот почему.

Sarah Goff-Dupont Sarah Goff-Dupont
Просмотр тем

Попрощавшись с неэффективными запретами на изменение кода и массивными слияниями монолитов, этим бичом централизованного управления версиями, разработчики могут обособлять незавершенную работу и без труда создавать продукт небольшими вертикальными фрагментами. Процессы создания веток и слияния проходят в Git так безболезненно, что многие команды выделяют по ветке каждой пользовательской истории или исправлению, над которыми они работают. Эта модель стремительно набирает популярность, постепенно становясь эталоном для agile-команд, и на то есть причины.

Запаситесь попкорном и включайте запись одного из наших самых популярных вебинаров. Из него вы узнаете:

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

Смотрите и учитесь

Вопросы и ответы

Интересно, правда же?

Признаюсь, я часто пропускаю ту часть вебинара, где аудитория задает вопросы, а ведущие на них отвечают. Если вы узнали сейчас себя, то знайте, что в этом нет ничего постыдного. Я записала несколько вопросов и ответов на них, чтобы вы могли бегло просмотреть и прочитать их на досуге.

Вопрос. У вас столько веток. Какой подход вы применяете для нумерации версий? Как вы разделяете строки кода?

Ответ. Обычно команды называют ветку так же, как соответствующую версию продукта. Например, когда команда, разрабатывающая Stash, работала над версией 2.9, они создали ветку стабильной версии под названием stash-2.9. Если найти ее в репозитории, сразу понятно, к чему относится эта ветка. Вы можете использовать для названий любой формат, который подходит команде, только не забудьте добавить к названию номер версии.

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

Ответ. Два человека могут работать над одной веткой задач. Главное, чтобы при этом они придерживались базовых правил этикета для работы над общей веткой, например не выполняли команду rebase и в целом старались не делать с локальной копией ветки ничего такого, что создавало бы проблемы для коллеги. Как вариант, каждый соавтор может создать собственную ветку для задачи, над которой они работают, и затем регулярно выполнять слияние обеих веток. Для названия веток можно использовать следующий формат: <имя/инициалы>-<ключ задачи>-<описание> (например, sarah-DEV-1234-company-name-misspelled-on-homepage). Примерно такой формат мы используем для названия веток, над которыми работают разработчики по одиночке.

Вопрос. Как поступать с зависимостями, если не выполнять слияние каждого изменения в одну ветку, как только оно применяется к ветке разработки?

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

Вопрос. Не так давно Мартин Фаулер высказался против использования функциональных веток. По его мнению, они препятствуют рефакторизации, и, пока работа над функциональной веткой не завершена, у вас идет не непрерывная интеграция, а непрерывная сборка.

Ответ. Да, я читала его публикацию по этой теме. По-моему, это было давно, году в 2008-м или 2009-м. Думаю, что с тех пор использовать CI для функциональных веток стало несколько удобнее. В той части вебинара, где я заостряла ваше внимание на некоторых особенностях модели «ветка на каждую задачу», я отметила, что ее использование не равно настоящему CI. Она обеспечивает непрерывную сборку и непрерывное тестирование, но не непрерывную интеграцию. Чтобы сделать процесс чуть более похожим на настоящее CI, можно включить в схему ветвления общую ветку интеграции.

продолжение темы
Code reviews