Djangers

Репозиторий для кейс-чемпионата «Разработка сервиса для тестирования знаний и навыков для сотрудников с компанией ООО «Флексайтс»

ПО:

• Python 3.10+
• PostgreSQL

Ссылка на макет: https://www.figma.com/team_invite/redeem/RPdI9YEHOvw15GFbQvUvGl

Как вытянуть проект из репозитория: Новое окно в VsCode, Открываем систему управления версиями -> клонировать репозиторий, в строку вводим: https://github.com/DrIwan/Djangers.git

Или клонировать командой:

git clone https://github.com/DrIwan/Djangers.git

Для Visual Studio Code добавлены рекомендуемые приложения, рекомендуется их установить

Настройка окружения

Backend

Рекомендуется создать виртуальное окружение и работать через него:

python -m venv venv

Активировать окружение на Windows:

venv\Scripts\Activate.ps1

Установить необходимые пакеты: pip install -r requirements.txt

Для удобной отладки приложения установить:

pip install django-debug-toolbar

Создаем файл настроек на основе шаблона:

cp backend/settings.py.example backend/settings.py

В settings.py заполнить SECRET_KEY и указать данные для подключения базы данных

Применить миграции базы данных:

python manage.py migrate

Запуск приложения:

python manage.py runserver

Frontend

cd frontend
npm install

Запуск

npm run serve

Работа с GitHub

1. Перед началом работы переключиться на ветку master

   git checkout

2. Вытянуть изменения

   git pull

3. Создаем ветку

   Название ветки должно отражать суть изменения в 2-3х словах

   git checkout -b feature/backend-api

4. Разрабатываем фичу

5. Добавляем файлы в систему контроля версий (add)

6. По ходу работы выполяем коммиты

7. Пушим ветку в удаленный репозиторий (GitHub)

   Опубликовать ветку

   git push -u origin feature/backend-api

   Далее можно пушить командой

   git push

8. В GitHub создаем Pull Request (PR)

   При создании перепроверить вносимые изменения.

   Название PR должно отражать суть изменений. Если необходимо, то указать описание.

   Если разработка еще не завершена, то можно указать статус Draft (черновик).

   По возможности заполнять все поля:

   • Reviewers - у кого запросить ревью, указывать когда внесены необходимые изменения или необходима помощь. Обычно тот, кто лучше знаком с изменяемой частью
   • Assignees - ответственный, обычно указывают себя
   • Labels
   • Projects
   • Development - Issue над которым ведется работа

9. Ожидать review

10. Перед мерджем в master проверить появились ли изменения

    Если есть изменения, то слить их к себе в ветку и проверить работоспособность

    git checkout master
    git pull

    Проверить работоспособность и закоммитить изменения

11. Через интерфейс GitHub слить изменения в ветку master

    Есть 2 основных способа слить изменения в мастер:

    • Create a merge commit - слить все коммиты
    • Squash and merge - собрать все изменения в один коммит

    Рекомендуется Squash and merge и он запомнит его по умолчанию

12. Удалить ветку