friflex_flutter_starter/tools/rfc/RFC-gitflow.md

Ведение проекта в git

Создание commits/pull-request

• язык описания PR - Русский;
• описание должно отражать краткую суть изменений;
• коммит/PR должен содержать:
  • исчерпывающую информацию об изменениях;
  • ссылку на задачу в таск-трекер;
  • Перечисление deprecated-кода (если есть).

Типы коммитов согласно convention

• feat: — новая функция

• fix: — исправление ошибок

• refactor: — Изменение кода, которое не исправляет ошибку и не добавляет функции (рефакторинг кода).

• build: — изменения, влияющие на систему сборки или внешние зависимости (примеры областей (scope): android, ios, linux и так далее).

• docs: — изменения только в документации

• chore - добавление/обновление/настройка инструментов и библиотек (пример: pubspec.yaml).

• test: — добавление недостающих тестов или исправление существующих тестов.

• ci: — изменения в файлах конфигурации и скриптах CI (примеры областей: папка CI).

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

Имена веток должны соответствовать convention, чтобы обеспечить консистентность и читаемость.

• Ветки feature должны начинаться с feat/.
• Ветки hotfix должны начинаться с fix/ и так далее
• Используйте номер задачи из таск-трекера в имени ветки.
• Добавьте краткое описание задачи, используя snake_case или kebab-case.

Пример:

• feat/PRIME-123_authentication
• fix/PRIME-456_typo_in_button
• fix/PRIME-456-typo-in-button

Схема разработки новой features

Создание релиза

Добавление новых features

• создаем ветку feat/(уникальный номер задачи) (название feature), Пример: PRIME-17 Добавить_локальный_репозиторий;
• вносим изменения;
• делаем коммит только на то, что касается изменений связанных с этой задачей;
• по завершению задачи - создаем Pull Request с названием по правилам https://commitlint.io/. Пример: feat(app,di,auth,scripts,pubspec): PRIME-17 Добавить локальный репозиторий. Где, PRIME- это обязательный префикс(с помощью него автоматически подтягивается ссылка на задачу), число 17 это уникальный номер задачи из трекера. В описание к PR добавляем ссылку на задачу и описание внесенных изменений, и пояснения(если требуется);
• после завершения CodeReview создаем squash commit в ветку main (название коммит(а), должно быть такое же как название pull request) ;
• после того как ветка с новой feature попало в main - удаляем ветку;

Создание release

• создаем ветку из main (release/release_0.0.1+1);
• добавляем в changelog.md описание изменений в этой версии (обычно это список коммитов, от предыдущей версии):
• делаем сборки, отправляем на тестирование;
• получаем баг-лист от тестировщиков, делаем фиксы;
• отправляем на следующий раунд тестирования и.т.д;
• после проверки и получения разрешение от другого разработчика - создаем tag c номером версии (0.0.1+1), создаем релиз, фиксируем версию и squash commit в ветку main и development;
• после того как release попал в main - удаляем ветку;