(Это инструкция, которую приходится копировать из проекта в проект, поэтому размещаю и в блоге.)

Gitflow

Идейно система работы с ветками берётся из Gitflow, но с упрощениями.

Общее

В нашем проекте ветка develop — ветка, которая содержит стабильный результат, который можно зарелизить на прод.

Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи/задачи:

• стабильного качества (по мнению разработчика (всегда) и менеджера (аппрув менеджера требуется, если этого требует конкретная задача);
• из спринта, который в работе (то есть те задачи, которые должны быть в ближайшем релизе).

Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).

Правила именования

Каждый коммит и пулл-реквест должны именоваться в следующем формате:

[Sentry] EDS-1004: <пояснение>

В квадратных скобках можно указать часть системы, которая затрагивается — это упростит поиск коммита, если что-то сломается. Списка частей системы нет, выбирайте на свой вкус. Из общих советов — это должно быть что-то широкое, чтобы был понятен контекст, но не слишком широкое, чтобы не терялся смысл.

EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.
Плюс почти все таск-трекеры позволяют сконнектиться с Gitlab/Github/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.

Работа с ветками

1. Из ветки main (или аналогичных prod/master) создается ветка develop.
2. На каждую фичу создаётся новая ветка вида feature/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера,  — краткое описание задачи на английском языке. Например: `feature/TASK-1777-change-forms-for-clients`.
3. Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.
4. Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.
5. Для релиза ветку develop мерджим в ветку main через MR в Gitlab/Githab/etc.
6. Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix/XXX-short-description.
7. Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.
8. После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.
9. Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.
10. Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.