Работа с системой контроля версий

Рекомендации по работе с системой контроля версий в процессе написания нового функционала, подготовки релиза и правке багов.

Описание

Подход напоминает сильно упрощённый git flow и почти полностью описывается следующей схемой:

По вертикали, сверху вниз: время.

По горизонтали, слева направо: ветки, в порядке их появления в рамках жизненного цикла проекта.

Например, для внесения нового функционала необходимо произвести следующие действия:

создать branch на базе актуального мастера с названием вида ${TASK_ID}/ft/${FEATURE_NAME}, где TASK_ID – идентификатор задачи в системе управления задачами;
внести необходимые изменения в рамках одного или нескольких коммитов;
произвести merge всех этих изменений обратно в мастер;
создать branch на базе текущего мастера с названием вида rel/${VERSION};
сразу сделать tag вида ${VERSION};
синхронизировать все изменения с сервером репозиториев, чтобы запустить подготовку релиза.

Формировать TASK_ID следует с учётом рекомендаций системы управления задачами, например для успешной интеграции с Atlassian Jira следует использовать исключительно верхний регистр.

Допустимы внесения изменений и без работы в отдельной ветке, в частности:

косметические правки и опечатки;
изменения, затрагивающие только окружение и инфраструктуру:
- версии зависимостей,
- CI-скрипты и манифесты,
- скрипты для подготовки релиза.

Для правки бага в свою очередь необходимо сделать следующее:

сделать checkout релизной ветки rel/${VERSION}, где ${VERSION} – версия проекта, затронутая багом;
внести необходимые для починки бага изменения;
синхронизировать изменения с сервером репозиториев, чтобы запустить подготовку релиза с текущей ветки;
перенести все изменения (merge или cherry-pick) на ветку master и на все релизные ветки с версией, больше чем ${VERSION}.

Также возможны случаи, когда правка бага происходит и в обратную сторону: необходимые для исправления бага изменения переезжают с ветки master на соответствующие релизные ветки, затронутые этим багом.

Предполагается, что в такой схеме минимальное время жизни feature-ветки – до момента появления изменения с этой ветки в master, а release-ветки – до окончания периода эксплуатации релиза этой версии.

Общие рекомендации

Основная ветка

Необходимо исключать попытки force push на ветку master, чтобы не портить жизнь ни коллегам, ни автоматизированным сервисам, работающим с вашим репозиторием. Для исключения такой возможности в сервисах хостинга репозиториях часто предусмотрены административные меры, не стоит ими пренебрегать.

Commit-сообщения

Каждый коммит должен быть снабжен четким и понятным сообщением, отображающим суть изменений. В качестве префикса сообщения рекомендуется использовать строку вида ${TASK_ID}: , где TASK_ID – тот самый идентификатор задачи в системе управления задачами.

Squashing

При подготовке feature или bugfix веток к слиянию, то есть при создании PR или MR, отправке на review, поощряется использование интерактивного rebase для объединения или разделения серий (не)связанных изменений, исключения из истории бессмысленных, повторяющихся и промежуточных наборов изменений, правки commit-сообщений.

В таких ситуациях force push на feature или bugfix ветки не только дозволяется, но и поощряется.

Актуальность feature-веток

Также перед подготовкой веток к слиянию или привнесении актуальных изменений хорошим тоном является rebase на целевую ветку (в подавляющем большинстве случаев – ветку master) для сохранения более понятной истории коммитов. Следует исключать появления _merge commit_ов на такого рода ветках.

6.7 KiB Raw Blame History Unescape Escape