При работе с Git важно выбрать подходящую модель ветвления, максимально отвечающую потребностям команды. Существует множество различных моделей. Например, Atlassian рассматривает 4 вида моделей. В этой статье мы рассмотрим модель Feature Branch Workflow.
Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.
Основная идея модели Feature Branch Workflow заключается в том, что вся работа над новой функциональностью должна производится в отдельной ветке, а не в ветке master. Такая инкапсуляция облегчает работу нескольких разработчиков над общей функциональностью в рамках одной кодовой базы. Также это значит, что нерабочий код никогда не попадет в ветку master, если процессы интеграции реализованы правильным образом и эффективно обеспечивают контроль качества.
Изоляция работы над новой функциональностью также позволяет эффективно использовать запросы на объединение кода (pull request, merge request), которые являются способом инициализации обсуждения изменений, созданных в ветке. Они дают другим разработчикам возможность одобрить функциональность перед интегрирацией в официальный проект. Или, если в процессе работы над функциональностью разработчик столкнулся с проблемой, он может создать запрос на объединение и спросить совета у коллег. Суть в том, что запросы на объединение позволяют участникам команды комментировать работу друг друга.
Модель Feature Branch Workflow можно эффективно использовать как базу для других высокоуровневых схем работы с Git. В модели Feature Branch Workflow в центре внимания – ветвление, это значит, что она является основной используемой моделью для создания веток и управления ими. Так, она обычно используется в моделях Gitflow и Forking Workflow для организации ветвления.
Как это работает
Модель работы Feature Branch Workflow предполагает наличие центрального репозитория, официальная история проекта представлена в ветке master. Вместо того, чтоб отправлять изменения сразу в локальную ветку master, каждый раз, начиная работу над новой функциональностью, разработчики создают новую ветку. Названия веток feature должны быть понятными, то есть должны давать представление о том, что разрабатывается на ветке, например animated-menu-items или issue-#1061. То есть, главное – создавать одну ветку для одной конкретной цели.
Кроме этого, ветки feature могут (и должны) отправляться в центральный репозиторий Git (push). Это позволяет дать доступ к функциональности другим разработчикам, не затрагивая официальный код. Так как master – единственная “особая” ветка, сохранение нескольких веток feature в центральном репозитории не вызывает проблем. И конечно, это удобно для отката локальных изменений. Далее мы бегло рассмотрим жизненный цикл ветки feature.
Начнем с ветки master
Все ветки feature создаются из наиболее актуального состояния кода проекта. Предполагается, что код поддерживается в актуальном состоянии и обновляется в ветке master.
git checkout master
git fetch origin
git reset --hard origin/master
С помощью данных команд репозиторий подключается к ветке master, вытягивает последние изменения и пересобирает локальную копию ветки master, чтобы она соответствовала последней версии.
Создание новой ветки
Для каждой функциональности или задачи, над которой вы работаете, используйте отдельную feature-ветку, например new-feature. После того, как вы создали ветку, разверните ее локально, чтобы вносить в нее изменения.
git checkout -b new-feature
С помощью этой команды можно перейти на новую ветку new-feature, созданную из master, флажок -b при этом говорит Git, что нужно создать ветку, если ее еще нет.
Обновление, добавление, подтверждение и отправка изменений
На данной ветке вы можете редактировать и фиксировать (commit) измения, как вы обычно это делаете, создавая столько фиксаций, сколько нужно для работы над функциональностью.
git status
git add <some-file>
git commit
Делаем отправку feature-ветки в удаленный репозиторий
Хорошей практикой является периодический вызов push для добавления изменений ветки feature в центральный репозиторий. Это позволит легко откатиться к предыдущему состоянию, а при обсуждении с другими разработчиками это даст им доступ к просмотру изменений в новой ветке.
git push -u origin new-feature
Данная команда отправляет new-feature в центральный репозиторий (origin), флаг -u добавляет ее как удаленную отслеживаемую ветку. После определения отслеживаемой ветки можно вызвать git push без параметров, чтобы автоматически отправлять ветку new-feature в центральный репозиторий. Чтобы получить комментарии к новой ветке feature, создайте запрос на объединение в сервисе управления репозиториями, если сервис Git, который вы используете поддерживает такую возможность.
Слияние запроса
Перед слиянием изменений (merge), возможно, понадобится разрешить конфликты, если другие вносили изменения в ветку, куда вы собираетесь влить ваши изменения. Когда ваш запрос на слияние подтвержден, и все конфликты решены, можно интегрировать код в ветку master.
Запросы на объединение
Помимо изоляции разработки новой функциональности, создание отдельной ветки позволяет вести обсуждения по созданным изменениям через запросы на объединение. При завершении работы над функциональностью изменения не сразу сливаются в master. Вместо этого, ветка feature отправляется на центральный сервер и создается запрос на объединение с просьбой о слиянии изменений с веткой master. Это дает другим разработчикам возможность проверить изменения до того, как они станут частью кодовой базы.
Проверка кода – основное назначение запросов на объединение, хотя они могут применяться и в других случаях, когда есть необходимость обсудить код с коллегами. Можно говорить о запросе на объединение как об обсуждении, посвященном определенной ветке. Это значит, что их можно использовать и в процессе разработки. Например, если разработчику нужна помощь с определенной функциональностью, все, что нужно сделать, это создать запрос. Заинтересованные участники будут автоматически оповещены об этом и смогут увидеть вопрос непосредственно рядом с нужным фрагментом кода.
Как только запрос принят, публикация новой функциональности производится точно так же, как в модели Centralized Workflow. Сначала убедитeсь, что локальная ветка master синхронизирована с удаленной веткой. Затем, сделайте слияние ветки feature с веткой master и отправьте изменения из master обратно в центральный репозиторий.
Пример
Ниже представим пример сценария, в котором используется модель работы с ветками feature. По сценарию команда делает ревью кода на основе запроса с новой функциональностью. Это один из примеров, для чего можно использовать данную модель.
Мария начинает работу над новой функциональностью
Прежде чем начать разработку, Мария должна создать изолированную ветку. Она может создать новую ветку с помощью команды:
git checkout -b marys-feature master
Она переходит на ветку marys-feature, основанную на master, флажок -b говорит Git, что нужно создать эту ветку, если ее еще нет. На этой ветке Мария редактирует и фиксирует изменения как обычно, создавая столько фиксаций изменений, сколько необходимо для работы над функциональностью.
git status
git add <some-file>
git commit
Мария идет на обед
Мария добавляет новый код в течение первой половины дня. Прежде чем идти на обед, она делает отправку изменений на ветке feature в центральный репозиторий. Это позволит легко откатиться к предыдущему состоянию, а при обсуждении с другими разработчиками это даст им доступ к просмотру кода в новой ветке.
git push -u origin marys-feature
Эта команда отправляет изменения ветки marys-feature в центральный репозиторий (origin), флажок -u добавляет ее как удаленную отслеживаемую ветку. После того, как ветка настроена как отслеживаемая, Мария может вызвать git push без каких-либо параметров, чтобы отправить свою функциональность.
Мария заканчивает разработку
Вернувшись с обеда, она завершает разработку функциональности. Прежде, чем сливать ее с веткой master, Марии необходимо создать запрос на объединение и оповестить команду о той работе, которую она сделала. Но сначала необходимо убедиться, что в центальном репозитории есть весь код.
git push
Затем, она создает запрос на объединение в Git UI, В запросах удобно то, что комментарии отображаются непосредственно рядом с кодом, что значительно облегчает обсуждение конкретного набора изменений.
Василий получает запрос на объединение
Василий получает запрос на объединение и просматривает изменения в ветке marys-feature. Он решает, что нужно внести небольшие изменения в код прежде, чем интегрировать эту ветку в официальный проект, поэтому они с Марией обсуждают изменения с помощью средств комментирования кода в запросе.
Мария вносит изменения
Для внесения изменений Мария использует ту же последовательность действий, которую она использовала в начале работы над функциональностью. Она редактирует, фиксирует и отправляет обновления в центральный репозиторий. Все ее действия отображаются в ранее созданном запросе, и Василий также может комментировать их по мере появляения изменений.
При желании, Василий мог бы слить изменения с ветки marys-feature в свой локальный репозиторий и работать с ними самостоятельно. При этом все его изменения также отражались бы в запросе.
Мария публикует новую функциональность
Как только Василий готов принять запрос на объединение, кто-то должен сделать слияние функциональности в stable-ветку (это может сделать как Василий, так и Мария):
git checkout master
git pull
git pull origin marys-feature
git push
В результате делается объединяющая фиксация. Некоторые разработчики отдают предпочтение такому подходу, потому что он похож на символическое объединение новой функциональности с остальной кодовой базой. Но если вы являетесь сторонником линейной истории изменений, можно использовать подход, основанный на rebase.
В некоторых интерфейсах можно автоматизировать процесс слияния запросов на объединение, кликнув на кнопку “Accept”, которая производит сразу все указанные выше команды. Если в вашем интерфейсе нет такой кнопки, то должна быть возможность автоматически закрыть запрос, когда производится слияние feature-ветки с master.
Заключение
В данной статье мы рассмотрели модель ветвления Feature Branch Workflow. Она помогает организовать и отслеживать ветки, ориентированные на набор функций предметной области. Другие модели работы с Git, такие как Forking Workflow и Gitflow ориетированы на репозитории и могут эффективно использовать модель Feature Branch Workflow для управления ветками. В статье приводится обобщенный пример кода, используемый в вымышленной ситуации, в которой применяется модель Feature Branch Workflow. Ключевые идеи, которые нужно запомнить о модели Feature Branch Workflow:
- Она ориентирована на шаблоны ветвления.
- Может быть использована вместе с другими моделями работы с репозиториями.
- Способствует общению в команде посредством запросов на объединение и ревью кода.
Использование rebase на стадиях ревью и слияния feature-ветки приведет к созданию связанной истории слияний. Модель ветвления Feature Branch Workflow – это отличный инструмент для совместной работы.
Если статья вам понравилась и была для вас полезной, поделитесь ей с друзьями.