Используем в работе модель Git Flow.
Клиент SourceTree поддерживает Git Flow из коробки.
Основные принципы:
- В ветки develop и master напрямую ничего не коммитим, все проводим через рабочие ветки.
- Каждый коммит в master — это по определению новый релиз со новой версией
- Ветки с фичами (feature/bugfix) не вливаем в develop, пока они не прошли тестирование и сode review
- Веткизакрываем после слияния
Типы веток
feature/ — ветка с фичей
bugfix/ — ветка с правкой бага
release/ — ветка с новым релизом
hotfix/ — ветка с правкой бага на продакшене
Модель
Задачи разработки (feature, bugfix)
Могут порождаться от: develop
Должны вливаться в: develop
Соглашение о наименовании: feature/dddd-*
В качестве имени ветки берем формат feature/1672-AddNewCar, где
- feature/ – префикс типа ветки из flow модели [feature, bugfix].
- 1672 – номер задачи (в bitrix24)
- AddNewCar– краткое англоязычное кодовое описание в CamelCase
В комментарии коммита необходимо писать тип ветки и номер задачи, например feature/1672 Описание коммита или bugfix/1673 Исправление ошибки
Когда разработчик считает, что выполнил задачу, прошли автотесты и выполнен code review (с помощью merge request), он в bitrix24 переносит тикет в столбец «Готово к тестированию». После этапа тестирования, если тесты не прошли, задача может вернуться в разработку.
В случае успешного прохождения тестов, специалист QA переводит задачу в столбец «Прошли тестирование»; далее, разработчик может влить задачу в ветку develop с последующим переводом статуса в «Готово к выкладке (develop)».
Релизы (release)
Могут порождаться от: develop
Должны вливаться в: develop и master
Соглашение о наименовании: release/d.d.d
Перед планируемой выкладкой от ветки develop отделяем release-ветку, в рамках которого изолируем от продолжающейся разработки уже готовые и влитые ветки задач для дальнейшего тестирования и фиксов.
Ветку именуем по типу release/2.1.18. В качестве формата для версии релиза используем модель:
MAJOR.MINOR.BUILD[.PATCH]
Для релиза номер PATCH всегда должен быть равен 0 и может быть опущен.
В bitrix24 работа в рамках релиза формируется в новый столбец. Например, «Релиз 2.1.18»; сигнатуру патча опускаем.
Когда релиз готов и оттестирован, вливаем его в ветки master и develop, маркируем состояние master’а тэгом с номером версии, а к названию столбца в bitrix24 добавляем дату выкладки, например: «Релиз 2.1.18 — 26.11.2018»
Хотфиксы (hotfix)
Могут порождаться от: master
Должны вливаться в: develop и master
Соглашение о наименовании: hotfix/d.d.d.d
В комментарии коммита необходимо писать номер задачи, например hotfix/1672 Описание ошибки.
Если в процессе эксплуатации релизной версии появляется необходимость исправить найденный баг, делаем ветку от текущего prod’а с названием вида hotfix/2.1.18.1, где инкрементируем номер патча от текущей версии.
По готовности вливаем его, как и релиз, в master и develop, и маркируем мердж соответствующим тэгом версии.
Тикеты в bitrix24 передвигаем в столбец существующего релиза (например, «Релиз 2.1.18 — 26.11.2018») и добавляем в их название хэштег релизной версии хотфикса (например, #2.1.18.1).
Именование коммитов
Коммиты в рамках ветки предлагается начинать с префикса вида: «#1745 — », – где 1745 номер задачи (в bitrix24), к которой относится коммит.
Например:
- feature/1745-AddNewTariff
- bugfix/1809-ImportTariffFiles
Например, в ветке hotfix/2.2.76.1 решается три мелких бага из системы учёта тикетов: #1751, #1752, #1753. Каждый из трех коммитов рекомендуется начать с номера, соответствующего задаче.