dmisim/friflex_flutter_starter
1
0
Fork 0
mirror of https://github.com/smmarty/friflex_flutter_starter.git synced 2026-02-05 03:32:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(readme): обновить структуру и содержание README.md, улучшить оформление (#27)

Browse Source 
Co-authored-by: petrovyuri <petrovyuri@example.com>
This commit is contained in:
Yuri Petrov
2025-09-17 12:46:45 +03:00
committed by GitHub
parent 03e189e46b
commit c295412f4d
9 changed files with 223 additions and 171 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
tools/rfc/RFC-gitflow.md
View File

@@ -1,60 +1,69 @@
# Ведение проекта в git
## Создание commits/pull-request
- язык описания PR - Русский;
- описание должно отражать краткую суть изменений;
- коммит/PR должен содержать:
- исчерпывающую информацию об изменениях;
- ссылку на задачу в таск-трекер;
- Перечисление deprecated-кода (если есть).
- исчерпывающую информацию об изменениях;
- ссылку на задачу в таск-трекер;
- Перечисление deprecated-кода (если есть).
### Типы коммитов согласно convention
* **feat**: — новая функция
* **fix**: — исправление ошибок
* **refactor**: — Изменение кода, которое не исправляет ошибку и не добавляет функции (рефакторинг кода).
* **build**: — изменения, влияющие на систему сборки или внешние зависимости (примеры областей (scope): android, ios, linux и так далее).
* **docs**: — изменения только в документации
* **chore** - добавление/обновление/настройка инструментов и библиотек (пример: pubspec.yaml).
* **test**: — добавление недостающих тестов или исправление существующих тестов.
* **ci**: — изменения в файлах конфигурации и скриптах CI (примеры областей: папка CI).
- **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.
- Ветки feature должны начинаться с `feat/`.
- Ветки hotfix должны начинаться с `fix/` и так далее
- Используйте номер задачи из таск-трекера в имени ветки.
- Добавьте краткое описание задачи, используя snake_case или kebab-case.
Пример:
* `feat/PRIME-123_authentication`
* `fix/PRIME-456_typo_in_button`
* `fix/PRIME-456-typo-in-button`
- `feat/PRIME-123_authentication`
- `fix/PRIME-456_typo_in_button`
- `fix/PRIME-456-typo-in-button`
## Схема разработки новой features
![](./tools/res/images/developing.jpg)
![Схема разработки новой features](./tools/res/images/developing.jpg)
## Создание релиза
![](./tools/res/images/release.jpg)
![Схема создания релиза](./tools/res/images/release.jpg)
### Добавление новых features
- создаем ветку feat/(уникальный номер задачи) (название feature),
Пример: <b>PRIME-17 Добавить_локальный_репозиторий</b>;
- вносим изменения;
- делаем коммит только на то, что касается изменений связанных с этой задачей;
- по завершению задачи - создаем Pull Request с названием по правилам https://commitlint.io/.
Пример: <b>feat(app,di,auth,scripts,pubspec): PRIME-17 Добавить локальный репозиторий</b>.
- создаем ветку 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 - удаляем ветку;
- после завершения 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 - удаляем ветку;
- создаем ветку из main (release/release_0.0.1+1);
- добавляем в changelog.md описание изменений в этой версии (обычно это список коммитов, от предыдущей версии):
- делаем сборки, отправляем на тестирование;
- получаем баг-лист от тестировщиков, делаем фиксы;
- отправляем на следующий раунд тестирования и.т.д;
- после проверки и получения разрешение от другого разработчика - создаем tag c номером версии (0.0.1+1), создаем релиз, фиксируем версию и squash commit в ветку main и development;
- после того как release попал в main - удаляем ветку;