📗 Запуск проекта

🔸 Установка

 git clone https://github.com/NikGor20/front_pmv4.git

🔸 Перейти в папку с проектом

 cd front_pmv4

🔸 Установка зависимостей

 npm i

🔸 запуск сервера разработки

 npm run serve

🚩 Используемые технолигии

• Vue 3 (composition API)
• Pinia - state management
• SCSS
• Quasar - ui library
• Eslint v8.57.0
• Vite

➿ Eslint команды

🔹 Проверка синтаксиса

 eslint --ext .js,.vue --ignore-path .gitignore src

🔹 Проверка синтаксиса и устранение ошибок

 eslint --ext .js,.vue --ignore-path .gitignore --fix src

📁 Структура проекта

 project/
├─ publick
│   ├─ images/
│   └─ icons/
├─ src
│   ├─ api/ обращения к API
│   ├─ assets/ Стили и шрифты
│   ├─ components/
│   │  ├─ block/ строительный материал для pages
│   │  └─ ui/ более мелкие компоненты для block
│   ├─ core/ Найстроки router, store, axios
│   ├─ layout/ шаблоны
│   ├─ pages/ странницы
│   ├─ shared/ переиспользуемый функционал
│   └─ utils/ валидаторы, конфигурации
├─ App.vue
├─ main.js
├─ .env
├─ .eslintrc.cjs
└─ vite.config.js

💡 Стратегия работы с Git (за основу взята стратегия GitFlow)

Стратегия Gitflow предполагает наличие постоянных веток для разработки и деплоя, а так же набора временных вспомогательных веток для работы с постоянными ветками.

Постоянные ветки:

• master. В ветке master хранится только рабочий код, готовый в любой момент к выгрузке в боевую среду.

• develop. Ветка develop предназначена для разработки. В нее сливаются оттестированные изменения из feature-веток, bugfix-веток и прочих. Потенциально может быть нестабильна.

Вспомогательные ветки:

• feature

Под каждую новую функциональность создается новая ветка feature. Создается всегда на основе ветки develop. Обратное слияние с веткой develop происходит только после полного тестирования новой функциональности.

• bugfix

Ветки bugfix предназначены для исправления ошибок предыдущих релизов. Аналогично веткам feature создаются на основании ветки develop.

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

• Название ветки должно четко и ясно давать представление о том, что именно делает код в данной ветке.
• Используется только нижний регистр.
• Используются только символы a-z, 0-9, не содержит специальных символов.
• Слова разделяются дефисами.
• В начале пишется название вспомогательной ветви, затем "/".
• Если есть оформленная задача, её номер необходимо добавить после названия вспомогательной ветви.:
• Пример именования веток:
  • feature/#4671-page-indi
  • bugfix/restore-password-error

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

• Название коммита должно быть информативными, отражать то, что делает код в этом коммите.
• Для подробного описания коммита следует использовать тело сообщения коммита(отделяется от заголовка пустой строкой).
• Желательно указывать префикс перед названием коммита.
  • feat - новая фича
  • fix - исправление ошибки
  • style - изменения, которые не влияют на смысл кода, связаны с форматированием кода, например пробелами, отсутствием точек с запятой и т.п.,
  • chore - изменения, которые не относятся к исправлению или новой функции и не изменяют src или тестовые файлы (например, обновление зависимостей)
  • docs - обновления документации, такой как README или других
  • refactoring - улучшение кода, не вносящее новой функциональности и не являющееся фиксом
  • build - изменения, влияющие на систему сборки или внешние зависимости
  • perf - оптимизация производительности
• Начинается с заглавной буквы без точки в конце.
• Код в коммите должен быть логически завершенным.
• Примеры коммитов:
  • feat: Improve performance with lazy load implementation for
  • chore: Update npm dependency to latest version
  • feat: Добавлена функция обработки аутентификации

Работа с запросами на слияние (pull requests) в ветку develop

Для того, чтобы слить изменения из одной ветки в другую используются запросы на слияние. Не допускаются коммиты напрямую в ветки develop и master.

Все новые ветки должны сначала сливаться в ветку develop, затем после тестирования на тестовом-домене, изменения вливаются через pull-request в master-ветку.

Запрос на слияние создается через веб-интерфейс. Нужно открыть код исходной ветки, в выпадающем меню Contribute выбрать пункт Open pull request. Либо на главной странице проекта нажать на кнопку Compare & pull request.

В верхней панели нужно проверить корректность заполнения исходной и целевой веток. Целевая ветка обозначена как base:, исходная как compare:.

Название запроса на слияние должно совпадать с названием исходной ветки.

В описании запроса нужно добавить:

• Назначение исходной ветки (новый функционал, исправление оибок и прочее)
• Общие сведения о том, что изменилось
• Какой функционал проекта был затронут внесенными изменениями
• Изображения или другой материал при необходимости.

В панели справа необходимо добавить:

• Ревьюеров для проверки кода. Раздел Reviewers
• Ответственного за слияние в целевую ветку. Раздел Assignees

После создания запроса на слияние github проверит наличие конфликтов между исходной и целевой ветками. Если нельзя автоматически слить ветки, появится соответствующее предупреждение.

В этом случае необходимо вручную локально в среде разработки слить ветку develop в рабочую ветку и через редактор разрешения конфликтов внести исправления. После чего отправить их в удаленный репозиторий.

[!CAUTION] Чтобы предотвратить часто возникающие конфликты слияния, следует дополнительно подтягивать изменения из develop в рабочую ветку не реже двух раз в день.