Общие правила ветвления проектов:
1. Введены следующие понятия:
a. Мажорная версия программы – версия программы в рамках определенной концепции, меняется при значительных изменениях концепции, обозначается v-m, где m – номер мажорной версии;
b. Минорная версия программы – подверсия в рамках одной концепции, меняется при добавлении нового функционала или незначительной переделке существующего, обозначается v-m-n, где m – номер мажорной версии, n – номер минорной версии;
c. Релиз программы – вариант минорной версии, номер релиза меняется при незначительных изменениях и/или исправлении багов в соответствующей минорной версии программы, обозначается r-m-n-p, где m – номер мажорной версии, n – номер минорной версии, p – номер патча;
2. Разработка нового функционала ведётся в ветке master. Ветка master защищённая, для помещения изменений в неё разработчиками выполняется merge-request. Решение по принятию merge-request принимает технолог на основании просмотра исходного кода вносимых изменений (code review).
3. Для каждой мажорной версии создается ветка разработки нового (дополнительного функционала). Для текущей мажорной версии это ветка master, для прошлых мажорных версий ветки разработки называются по шаблону: dev-v-m, где m – номер мажорной версии. Работа с этой веткой аналогична работе с веткой master. Для каждой ветки dev-v-m создается своя база данных и именуется по шаблону project_name_dev_v_m. Ветка разработки для мажорной версии создается сразу после начала работы над следующей мажорной версии.
4. Каждая задача – это новая тематическая ветка, которую должен создать разработчик перед началом выполнения задачи. Ветки создаются на основании текущего коммита ветки в которой должна быть выполнена задача. Ветки именуются по шаблонам:
a. t-xxxxx, если это задача на разработку нового функционала (xxxxx – номер задачи из корпоративной системы)
b. b-xxxxx, если это задача по исправлению бага (xxxxx – номер задачи из корпоративной системы).
5. После выполнения задачи и помещения коммитов тематической ветки в ветку, для которой выполнялась задача, разработчик удаляет тематическую ветку.
6. При постановке задачи на исправление бага нужно указывать минорную версию, в которую нужно вносить изменения, например, в версию v-1-1 (если ничего не указано, то баг исправляется в тестируемой на данный момент минорной версии). При исправлении бага в ветке master, главный технолог должен принимать решение о необходимости включения этого исправления в ветку с актуальной версией. Задачи по добавлению функционала предполагают помещение их в ветку master по умолчанию, иначе должна быть указана конкретная ветка (ветки) разработки прошлой мажорной версии.
7. Периодически (по мере реализации функционала) формируются минорные версии. Каждая минорная версия – это отдельная ветка. Ветка минорной версии обозначается по шаблону v-m-n, где m – мажорный номер версии, n – минорный номер версии. В рамках версий формируются релизы. Релизы формируются тогда, когда исправлены все обнаруженные баги в тестируемой минорной версии. Релиз обозначается тегом формата r-m-n-p, где m – мажорный номер версии, n – минорный номер версии, p – номер патча (патч выпускается только для исправления багов). После создания ветки минорной версии в ней правятся только баги. Ветка минорной версии создается главным технологом в момент окончания разработки функционала версии, но до начала основного тестирования. При формировании минорной ветки, нужно дополнять в проекте файл с изменениями в этой версии по отношению к предыдущей.
8. После формирования релизного тега, ветка минорной версии должна быть слита с основной веткой разработки.
9. После выпуска релиза следующей минорной версии, поддержка предыдущей минорной версии прекращается.
10. В начале работы над проектом нет смысла в создании минорной версии, в которой исправляются только баги, т.к. данная версия не предоставляется внешнему заказчику. Поэтому до формирования первой минорной версии тестирование происходит на базе ветки master и баги исправляются в ней же. На более поздних этапах проекта, когда еще нет необходимости передавать версии, но уже появилась потребность проводить демонстрации можно начать создавать минорные версии, но в этом режиме обнаруженные и исправленные в минорной версии баги должны обязательно исправляться и в ветке разработки (минорная ветка должна сливаться с веткой разработки). При этом демонстрации всегда выполняются на текущем релизе с протестированным функционалом, а не на последних разработках.
11. Небольшую доработку функционала можно вносить в ветки минорной версии, но это только в крайних случаях.
12. Коммиты именуются по следующему правилу: t-#####-taskname или b-#####-bugname.
взято с https://habr.com/ru/post/538420/