Есть ли широко используемые шаблоны для наименования веток в системе git?
Если есть статьи или другие обучающие материалы по данной тематике, пожалуйста, приложите их к ответу на данный вопрос.
Ответы
Ответ 1
Git Flow
Основные ветки
Ветки master и develop считаются основными ветками, их смысл состоит в том, что он
существуют до тех пор, пока существует сам проект. В ветке master всегда хранится стабильная версия проекта (релиз), в ветке develop хранится текущая рабочая версия проекта.
Вспомогательные ветки
Кроме основных веток существуют так же и вспомогательные, которые используются дл
добавлений фич в проект, реализации багфиксов и подготовки релизов. Каждая такая ветк
существует до тех пор, пока ведётся работа над задачей, для которой она была создана, после чего она удаляется, предварительно сливаясь с одной из основных веток (или сразу с двумя), если задача была успешно выполнена.
Используются следующие типы веток:
Ветки функциональностей (Feature branches)
Ветки функциональностей могут иметь произвольные названия, которые очень кратко описывают суть задачи, для которой они создаются.
Порождается от ветки develop и используются для внедрения в проект дополнительных функций (фич), после чего вливается обратно в develop.
Ветки релизов (Release branches)
Название имеет вид release-*.
Когда появляется надобность в новом релизе, создаётся ветка релиза, происходяща
от develop, в которой происходят косметические изменения, необходимые для релиза. После этого ей присваивается версия (тег) в соответствии с принятым в компании стандарте нумераций версий и она вливается в обе основные ветки, master и develop.
Ветки исправлений (Hotfix branches)
Название имеет вид hotfix-*.
Если в текущей стабильной версии проекта (которая хранится в master) выявляется баг
который требует немедленного исправления, создаётся ветка багфикса (исправления), порождённая от master. После удачного исправления бага вливается в master и develop.
Источник
Ответ 2
GitLab Flow
GitLab Flow даёт достаточно подробные рекомендации по именованию веток.
Стабильные ветки
Стабильные (долгоживущие, stable, long-living) ветки именуются соответственно окружения
(environments), на которые разворачивается (deploy) код из последнего коммита этой ветки. Исключение делается для ветки master, которая разворачивается на staging, либо сразу на production.
<ветка> → <окружение>:
master → staging («предпоследний рубеж» тестирования, интеграционные тесты)
pre-production → pre-production («последний рубеж», бета-тестеры и приёмка)
production → production (то, что мы предоставляем клиентам)
Это правило даёт максимальный эффект, когда вы настраиваете автоматическое развертывание приложения в соответствующую среду. То есть:
Появление нового коммита в ветке master означает, что у вас появился новый релиз-кандидат
который идёт на staging. Там на нём должны запускаться интеграционные тесты, там на него смотрит менеджер продукта и/или заказчик, там его тыкают бета-тестеры и т.п.
Появление нового коммита в production означает релиз очередной версии. Поскольк
у коммита есть дата и автор, вы всегда будете знать, кто и когда принял решение о релизе.
Вы всегда знаете, какая версия кода находится в каждом из окружений. Если где-т
обнаружен баг (хорошо, когда не на продакшене), не составит труда найти содержащую его версию.
Разумеется, ветки нужно защищать, чтобы выпускать релизы мог только ответственный за это человек.
Версионные ветки
Если вы выпускаете поддерживаемые версии продукта, используйте для них версионны
ветки (version branches) с единообразными именами, содержащими номер версии и некоторый идентификатор версионной ветки, например:
1-2-stable
1-3-stable
Ветки фич
Для решения конкретных задач из трекера (системы учета задач) используются отдельны
ветки фич (feature branches). У каждой задачи есть номер и название (заголовок). Соответственно, ветка для этой задачи должна иметь вид:
<номер-задачи>-<заголовок-задачи>
То есть, если в нашем трекере есть две задачи:
Make hello world
Write readme
То соответствующие ветки должны называться:
1-make-hello-world
2-write-readme
Если заголовки задач у вас в кириллице или любом другом не-ASCII алфавите, то, пожалуй
названия веток лучше переводить. Наверное, можно и транслит использовать, но мне кажется
что его сложно читать. На этот счёт в GitLab Flow нет конкретного правила, поэтому вам нужно самостоятельно выработать внутрикомандное правило. Тут допустимы вольности, потому что вы всегда можете точно сопоставить ветку с задачей по их номеру.
Ответ 3
GitHub flow
По сравнению с другими вариантами, GitHub Flow проще, но и ограниченнее.
Он неплох для хорошо дисциплинированных команд, способных выпускать в продакшн кажду
фичу сразу по мере готовности без серьёзных поломок. Это требует хорошего автоматического QA/QC и/или стальных нервов.
В нём ветки делятся на две категории:
Единственная стабильная ветка master, содержащая последнюю стабильную версию, готовую к разворачиванию в любой момент.
Ветки фич, для pull request'ов в master, названные таким образом, чтобы можно был
догадаться, о чём фича. Средствами гитхаба обычно настраивается ряд проверок для каждог
pull request'а, успешное прохождение которых удостоверяет, что принятие ничего не поломает. Этими проверками может быть инспекция кода (code review), запуск тестов или даже развёртывание на временную среду, где с результатом может поиграть кто угодно.
В теории, можно ещё делать pull request'ы к pull request'ам, при работе над особ
крупными вещами, которые надо принимать только целиком или не принимать вообще. Но на практике я с таким не сталкивался.
Примеры названий веток, приводимые самим гитхабом:
refactor-authentication
user-content-cache-key
make-retina-avatars
Всё. Больше ничего нет. Релизы обозначаются метками (tag), хотфиксы фактически приводят к новым релизам и, соответственно, новым меткам.
Но из-за ограниченности и простоты, как правило, его расширяют.
К примеру, по мере развития проекта обычно возникают версионные ветки. Скажем, есл
намечается группа версий, в которую придётся "бэкпортить" (backport, портировать на старую версию) новые фичи или исправления, то для неё можно создать свою именованную ветку, эту группу версий объединяющую, обычно по неполному номеру версии или маске:
{неполный-номер-версии}-stable, например 4-0-stable (Rails)
stable/v{неполный-номер-версии}, например stable/v0.6 (noVNC)
v{маска-версии}, например v1.x (vega)
{неполный-номер-версии}-releases, например 1.0-releases (atom)
Комментариев нет:
Отправить комментарий