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

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

Конфигурация

Настоятельно рекомендуется настроить глобальный gitignore:

$ git config --global core.excludesFile '~/.gitignore'

Для удобства можно воспользоваться сервисом gitignore.io

Пример минимального глобального gitignore:

## Tool: rebar3
_checkouts/

## Tool: EDTS
.edts

## Tool: *tags
.tags*
tags

## Editors: temp files
*~

## Editor: Sublime
*.sublime-workspace

## Editor: Emacs
\#*
.\#*
.projectile
.dir-locals.el

## Editor: IntelliJ IDEA
out/
.idea/

## OS: macOS
.DS_Store

Описание

Подход напоминает сильно упрощённый 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_ов на такого рода ветках.

7.3 KiB Raw Blame History Unescape Escape