Перейти к содержанию

Правила ведения git

Важно: Требуется дополнить статью, описав правила ведения веток, тестирования, релизов и т.д.

Формат Комментариев к Коммиту

  1. Заголовок Коммита:
  2. Формат: <Область>: <Тип изменения>: <номер задачи>: краткое описание
  3. Длина: Не более 50 символов.
  4. В заголовке обязательно указывать номер задачи (очередь + номер, например, PLQM-1234) как тег.
  5. Область изменений:
    • core — изменения в ядре системы (базовая функциональность)
    • ibp — изменения в шаблоне IBP (Integrated Business Planning)
    • apps — изменения в других приложениях бизнес-логики

  6. Типы изменений:

    • feat: Добавление нового функционала.
    • fix: Исправление ошибок.
    • docs: Изменения в документации.
    • style: Изменения, не влияющие на код (например, форматирование).
    • refactor: Изменения в коде, которые не исправляют баги и не добавляют новые функции.
    • test: Добавление или исправление тестов.
    • chore: Обновление задач сборки или вспомогательных инструментов и библиотек.

  7. Тело Коммита (опционально):

  8. Описание: Более детальное описание изменений.
  9. Формат: Каждая строка не более 72 символов.

  10. Содержимое: Объясните, что изменилось и почему. Укажите, если изменения решают какую-то проблему или добавляют новую функциональность.

  11. Футер Коммита (опционально):

  12. Использование: Для указания дополнительных метаданных, таких как ссылки на задачи или тикеты.
  13. Пример: Closes #123, Refs #456.
  14. Ссылка на задачу в трекере (@https://tracker.yandex.ru/QUEUE-XXXX) может быть добавлена в конце футера по желанию.

Пример Коммита

core: feat: PLQM-1234: добавлен новый модуль авторизации

Добавлен новый модуль авторизации, который поддерживает OAuth2. 
Это позволит улучшить безопасность и упростить процесс входа для пользователей.

Closes #789
@https://tracker.yandex.ru/PLQM-1234

ibp: fix: IBP-124: исправлен расчет KPI для S&OP (refs #124)

apps: docs: APPS-125: обновлена документация по импорту данных (#125)

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

  • Указывайте область изменений: core, ibp или apps в начале заголовка коммита.
  • Будьте краткими: Заголовок должен быть кратким и информативным.
  • Будьте ясными: Тело коммита должно четко объяснять, что и почему было сделано.
  • Используйте активный залог: Пишите в активном залоге, чтобы сделать коммиты более понятными.
  • Следуйте стандартам: Используйте стандарты, такие как Conventional Commits, для обеспечения согласованности.
  • Указывайте ссылку на задачу: Включайте ссылку на задачу, в рамках которой был сделан коммит, так как это необходимо для интеграции с трекером.

Стратегия Ветвления и Слияния

Основные Ветки

  1. main (основная ветка):
  2. Содержит стабильный код, готовый к релизу
  3. Защищена от прямых коммитов
  4. Принимает только слияния из ветки test

  5. Каждый коммит в main должен быть тегирован версией релиза

  6. test (тестовая ветка):

  7. Содержит код, прошедший тестирование
  8. Принимает слияния из ветки dev
  9. Используется для финального тестирования перед релизом

  10. После успешного тестирования сливается в main

  11. dev (ветка разработки):

  12. Основная ветка для разработки
  13. Принимает слияния из веток разработчиков
  14. Используется для интеграционного тестирования
  15. Регулярно сливается в test

Ветки Разработчиков

  1. Формат имени ветки: 
    TASK-123_краткое_описание_задачи
    где:
  2. TASK-123 - номер задачи в трекере

  3. краткое_описание_задачи - краткое описание на английском языке

  4. Подготовка к работе:

  5. Перед началом работы над задачей создается Merge Request в git-интерфейсе
  6. Merge Request создается из будущей ветки в dev
  7. В описании Merge Request указывается:
    • Ссылка на задачу в трекере
    • Краткое описание планируемых изменений

  8. Merge Request остается открытым на весь период работы над задачей

  9. Правила работы с ветками:

  10. Создаются от ветки dev
  11. Одна ветка = одна задача
  12. После завершения работы сливаются обратно в dev
  13. Должны быть актуальными (регулярный rebase с dev)

Hot-fix Процесс

  1. Создание hot-fix ветки: 
    hotfix/TASK-123_краткое_описание
  2. Создается от ветки main

  3. Используется для срочных исправлений в production

  4. Процесс работы с hot-fix:

  5. Исправление вносится в hot-fix ветку
  6. Тестируется через слияние в test
  7. После успешного тестирования сливается в main
  8. Версия в main инкрементируется (patch)
  9. Изменения также сливаются в dev

Процесс Слияния

  1. Слияние в dev:
  2. Создается Pull Request

  3. Сливается в dev

  4. Слияние в test:

  5. Происходит после фиксирования в dev

  6. Требует нагрузочного тестирования и тестирование базового функционала

  7. Слияние в main:

  8. Происходит только после успешного тестирования в test
  9. Требует создания тега версии