Промышленное программирование

Лекция 6. Модели ветвления

Модели ветвления

В современной разработке VCS не только про контроль изменений, но и про организацию процессов (разработки, релизов, стабилизации, ...)
VCS позволяют координировать процессы в крупном проекте, контролируя основные этапы
Модели ветвления (workflow) - практики, упрощающие работу над проектом (которые за нас уже кто-то придумал)
Смысл модели ветвления в том, чтобы организовать добавление и публикацию изменений в исходном коде репозитория, управление различными версиями, понимание changelog'а релизов, ...

Модели ветвления

Модель ветвления - это не правило, которому нужно следовать, а скорее путеводитель
Можно просто выбрать определенные аспекты и сочетать их так как вам нужно
Несколько примеров: Feature Branch Workflow, Gitflow, Trunk-Based Development

Central Workflow

В репозитории существует одна ветка master, все изменения коммитятся напрямую в нее
Подходит для ведения проекта одному-двум людям, например, какой-то pet project, учебный проект или хранилище dot файлов - когда не нужны гарантии качества, стабилизация, тестирование и т.п.

Feature Branch Workflow

Вся работа над новой функциональностью должна производится в отдельной ветке (вероятно, несколькими разработчиками)
Такая инкапсуляция облегчает работу нескольких разработчиков над общей функциональностью в рамках одной кодовой базы
Также это значит, что нерабочий код никогда не попадет в ветку master, если процессы интеграции реализованы правильным образом и эффективно обеспечивают контроль качества
Допускаются долгоживущие ветки, когда фича отлаживается внутри отдельной ветки - из-за этого могут возникать проблемы при слиянии, так как за время жизни ветки кодовая база может сильно поменяться
Для облегчения слияния таких долгоживущих веток можно переодически выполнять rebase на главную ветку

Feature Branch Workflow

Новая функциональность при добавлении должна проходить процесс код-ревью
Код-ревью возможен как на этапе слияния в master, так и при добавлении отдельных изменения в feature branch
В PR производится доработка недостатков, выявленных другими разработчиками
В master должна сливаться уже полностью готовая функциональность, которую хоть сразу же можно выкатывать на пользователей

Feature Branch Workflow

git checkout -b new-feature (лучше давать осмысленные названия веткам, например, содержащие тикет)
git push -u origin new-feature
git merge new-feature
Кроме этого, от new-feature можно отводить дополнительные ветки: git checkout new-feature; git checkout -b change-for-feature

Trunk-Based Development

Trunk-Based Development не является новым подходом. Он был тактически продуман еще в восьмидесятых годах, а с середины девяностых стал набирать популярность. Крупнейшие разработчики программных продуктов, такие как Google и Facebook, широко применяют данный подход в организции разработки
Разработчики совместно работают над кодом в одной ветке, называемой «главной» (master или main в Git)
Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни
Данный подход позволяет разработчикам избежать сложностей связанных со слиянием веток

Trunk-Based Development

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

Gitflow

Модель ветвления Gitflow была впервые опубликована и стала популярной, благодаря статье Vincent Driessen
Предполагает выстраивание строгой модели ветвления вокруг релиза проекта, которая дает надежную схему управления крупными проектами
Отлично подходит для проектов, которые имеют спланированный цикл релиза

Gitflow

Кроме feature-веток в Gitflow используются отдельные ветки для подготовки, поддержки и записи релиза
Gitflow использует собственный набор инструментов git-flow, который легко интегрируется с Git, добавляя новые команды Git
В ветке master хранится официальная история релиза, а ветка develop служит в качестве интеграционной ветки для новых функций
Удобно тегировать все коммиты в ветке master номером версии
Ветка develop отводится от ветки master в начале работы над проектом

Gitflow

git branch develop
git push -u origin develop
(при работе с git-flow) git flow init

Gitflow

Каждая новая функциональность должна разрабатываться в отдельной ветке
Ветки функций создаются не на основе master, a на основе develop
Когда работа над новой функциональностью завершена, она вливается назад в develop
Новый код не должен отправляться напрямую в master

Gitflow

git checkout develop
git checkout -b feature_branch
(при работе с git-flow) git flow feature start feature_branch

Gitflow

git checkout develop
git merge feature_branch
(при работе с git-flow) git flow feature finish feature_branch

Gitflow

Когда принято решение о релизе, от ветки develop создается ветка release
Новая функциональность в релиз не добавляется, а только исправляются баги
Когда все готово, ветка release сливается в master, и ей присваивается тег с версией
Кроме этого, она должна быть также слита обратно в ветку develop

Gitflow

git checkout develop
git checkout -b release/0.1.0
(при работе с git-flow) git flow release start 0.1.0

Gitflow

git checkout develop
git merge release/0.1.0
(при работе с git-flow) git flow release finish '0.1.0'

Thank you

Лекция 6. Модели ветвления