Репозиторий и GitFlow

Используется git c тремя основными ветками master, stage, develop. Их нужно создать при инициализации проекта. У ведущего разработчика должны быть права напрямую пушить во все ветки. Для разработчиков три главные ветки защищаются, чтобы сливать в них только через merge-request (pull-request).

develop

1. Для каждой задачи от develop исполнителем создаётся новая ветка, именуется в формате feature/code-task-name.
2. В конце рабочего дня обязательно закоммитить и запушить в gitlab текущие правки по задаче даже если задача полностью не выполнена.
3. После выполнения задачи ветка feature/code-task-name сливается с develop через merge-request (запрос на слияние от исполнителя) в gitlab.
4. Ведущий разработчик делает ревью, принимает merge-request или пишет/сообщает свои замечания по коду. Пока merge-request открыт, новые комиты автоматически будут учитываться в нём.
5. Если есть конфликты для слияния, то разработчик самостоятельно подливает ветку develop к ветке с задачей локально без запросов на слияния, правит конфликты, пушит комиты с правками в ветке задачи.
6. Ветка develop деплоится автоматически на dev-сервер, на котором проводятся тесты командой разработчиков, но клиенту dev-сервер не демонстрируется.
7. После слияния старые ветки задач удаляются, чтобы не засорять репозиторий.

stage (release)

1. По завершению всех задач спринта ветка develop сливается в ветку stage ведущим разработчиком.
2. После слияния создается тег с номером спринта, например: s89.
3. Ветка stage деплоится на стейдж сервер, который доступен клиенту. На стейдж сервере проводится демо проекта.
4. Выявленные баги спринта правятся в отдельных ветках от ветки stage так как параллельно может вестись работа по новому спринту в ветке develop.
   • Ветка для багов в формате fix/code-bug-name.
   • После слияния баг-веток в stage добавляется новый тег с минорным инкрементом, например: s89.01.
   • Обновленная ветка stage с исправленными багами подливается в develop.
5. Пока задачи текущего спринта из develop не слиты в stage, работы по новому спринту не начинаются.
   • В исключительных случаях ветки новых задач создаются, но не сливаются в develop до релиза предыдущего спринта.

master

1. После принятия задач спринта ветка stage сливается в master ведущим разработчиком.
2. Добавляется тег с номером новой версии продукта. Для удобства используется номер спринта: v89.
3. Ветка master деплоится по согласию клиента на production сервер.
4. Если выявляются критические баги уже в продакшене, то от ветки master для исправления каждого бага создаются ветки в формате hotfix/code-bug-name.
   • После слияния баг-веток в master добавляется тег с минорным инкрементом, напрмиер: v89.01
   • Ветки с багами также сливаются в develop или другой вариант — обновленная ветка master подливается в develop.
   • Если идёт приемка спринта, то исправления подливаются и в stage ветку. Чтобы после его слияния в master баги были учтены.