📑 Оглавление

• 📌 Правила

  • 📂 Правила наименования веток
  • 📑 Формат заголовка Pull Request
  • 📝 Описание Pull Request
  • 📑 Правила проведения код-ревью (Pull Request Review)
  • 🌿 Ветвление и объединение изменений (Git Flow)
  • 📢 Важное сообщение

  ---

📌 Правила

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

---

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

Ветки в репозитории должны соответствовать следующему паттерну:
tasks/{порядковый номер}/{название ветки}

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

• tasks/tech/1/add-oauth-authentication

• Тип изменений: новая функциональность, добавлен OAuth-аутентификатор.

• tasks/assistant/2/fix-discount-calculation

• Тип изменений: исправление ошибки в расчете скидки.

• tasks/tech/5/ci-setup

• Тип изменений: настройка CI/CD для нового репозитория.

---

📑 Формат заголовка Pull Request

Название PR должно начинаться с **типа изменения** в квадратных скобках. В некоторых случаях могут использоваться **дополнительные флаги**, также заключенные в квадратные скобки и разделенные пробелами.

Типы изменений и их использование

• 🔹 [Feature] – Используется при добавлении новой функциональности, которая не нарушает обратную совместимость.
  ✅ Пример: [Feature] Реализация нового механизма авторизации

• 🔹 [Fix] – Указывается при исправлении ошибок или багов, не изменяя совместимость API.
  ✅ Пример: [Fix] Исправление логики расчета скидки

• 🔹 [Private] – Применяется для внутренних изменений, таких как рефакторинг, улучшение структуры кода, не влияющих на поведение системы.
  ✅ Пример: [Private] Оптимизация работы с базой данных

• 🔹 [BREAK] – Дополнительный флаг, указывающий, что изменения ломают обратную совместимость. Используется вместе с основным типом.
  ✅ Пример: [Feature] [BREAK] Обновлен формат JSON-ответов API

• 🔹 [CI] – Указывает, что PR касается инфраструктурных изменений, связанных с CI/CD процессами, настройками сборки и деплоя.
  ✅ Пример: [Private] [CI] Настроен автоматический деплой в тестовое окружение

• 🔹 [CherryPick] – Используется, если PR является переносом (cherry-pick) изменений из другой ветки.
  ✅ Пример: [Fix] [CherryPick] Исправлена ошибка расчета налога из ветки release-1.2

---

📝 Описание Pull Request

При создании PR необходимо добавить подробное описание, содержащее:

1️⃣ Введение

• 🔹 Здесь кратко укажите, почему был создан этот PR, какова его цель и какие проблемы решаются.

2️⃣ Краткое объяснение сути изменений

• 🔹 Описание самих изменений, что было сделано и зачем. Опишите, как эти изменения улучшат проект или решат конкретную задачу.

3️⃣ Как протестировано

• 🔹 Важно указать, как именно был протестирован функционал. Укажите использованные методы тестирования, окружение или шаги, которые были выполнены для проверки.

4️⃣ Дополнительную информацию о влиянии изменений

• 🔹 Укажите, как изменения могут повлиять на другие части системы, особенно если они затрагивают API, безопасность или важные модули проекта.

---

📑 Правила проведения код-ревью (Pull Request Review)

📌 Основной процесс

1. Разработчик создает Pull Request (PR)

   • PR должен содержать осмысленное описание изменений.
   • Указываются цель, ключевые изменения и важные детали в описании PR.

2. Ревьюер проверяет код

   • Оценивает читаемость, производительность и соответствие код-стилю.
   • При необходимости оставляет комментарии и замечания.

3. Разработчик вносит правки

   • Вносит исправления в рамках того же PR.
   • В комментариях к замечаниям сообщает, что исправлено.

4. Ревьюер повторно проверяет код

   • Оценивает исправления.
   • Если все замечания устранены, одобряет PR.

5. Разрешение комментариев

   • Комментарий может закрыть только тот, кто его оставил.
   • Если у ревьюера нет больше замечаний, PR может быть смержен.

🛠 Рекомендации

✔ Соблюдайте уважительный и конструктивный тон.
✔ Делайте правки в рамках одного PR, не создавайте новые.
✔ Разделяйте большие PR на логические части для удобства ревью.
✔ Старайтесь предоставлять обоснования к своим замечаниям.

---

🌿 Ветвление и объединение изменений (Git Flow)

При работе с репозиторием важно соблюдать чистоту основных веткок и правильно объединять изменения.

🔹 Структура базовых веток в проекте:

• master-base – ветка, содержащая шаблоны заданий, описание лабораторных, не предусмотрена для изменения студентами.
• master – основная ветка курса, в нее будут нацелены все студенческие изменения.

🔹 Основные правила Pull Request'ов:

• Каждый Pull Request должен содержать только логически связанные изменения, относящиеся к решению конкретной задачи.
• Перед объединением (merge) необходимо выполнить squash (объединение коммитов), чтобы не засорять историю основной ветки.
• Исключение – если Pull Request обновляет основную ветку с важными изменениями (синхронизация основных веток), тогда применяется обычный merge, чтоб сохранить информацию о внесенных изменениях. Например, ветки master c веткой master-base.

🔹 Какой merge использовать?

• ✅ Squash and Merge – для объединения всех коммитов Pull Request'а в один, чтобы история была чистой.
• ✅ Merge with all commits – только для синхронизации базовых веток.

---

📢 Важное замечание

❗ Каждое задание в лабораторной работе должно быть выполнено в отдельном pull request. Это необходимо для того, чтобы облегчить процесс проверки и следить за прогрессом выполнения каждого задания.

• 🔹 Если вы хотите внести любую другую правку в решении, создавайте новый pull request.

Инструкция:

1. Создайте новый pull request для каждого задания.
2. Убедитесь, что pull request включает только решение одного задания (например, Задание 1).
3. В комментарии к pull request укажите, какое задание вы выполняете и что было сделано.
4. После выполнения pull request, создайте новый для следующего задания.

Таким образом, ваши задания будут легче проверяться, и процесс будет более структурированным, прозрачным и организованным.

---

Следование этим правилам поможет сделать код-ревью быстрее и понятнее для всей команды 🚀

---