Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
70 lines (50 loc) · 4.54 KB

CONTRIBUTING.md

File metadata and controls

70 lines (50 loc) · 4.54 KB

Внесение правок

Основные советы

  1. Никогда не используйте merge, только rebase для сохранения линейной истории коммитов
  2. Осторожно с изменениями в чужих ветках. Придется больно и мучительно делать rebase. Лучше не трогайте чужие ветки
  3. Перепроверьте историю коммитов перед созданием пулл реквеста
  4. Каждый коммит должен быть осознанным и быть одним логическим элементом
  5. Каждый пулл реквест должен быть осознанным и быть одним логическим элементом
  6. Перепроверьте, что вы в правильной ветке, никогда не коммитьте напрямую в main

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

Коммиты добавляются в соответствии с conventional commits. Т.е <type>(<scope>): <body>.

Поле <type> должно принимать одно из этих значений:

  • feat для добавления новой функциональности
  • fix для исправления бага в программе
  • refactor для рефакторинга кода, например, переименования переменной
  • perf для изменения кода, повышающего производительность
  • test для добавления тестов, их рефакторинга
  • struct для изменений связанных с изменением структуры проекта (НО НЕ КОДА), например изменение расположения папок
  • ci для различных задач ci/cd
  • remove для удаления

Поле <scope> опционально и показывает к какому модулю, классу, методу функции и т.п применены изменения.

Поле <body> содержит суть изменений в повелительном наклонении настоящего времени на английском языке без точки в конце, первое слово - глагол с большой буквы. Текст сообщения должен включать мотивацию к изменению и контрасты с предыдущим поведением.

Примеры:

  • Хорошо: "Add module for future BST implementations"
  • Плохо: "Added module for future BST implementations."
  • Плохо: "Adds module".
  • Очень плохо: "new bug."

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

  1. Из ветки develop создается ветка release.
  2. Из ветки develop создаются ветки feature.
  3. Когда работа над веткой feature завершается, она сливается в ветку develop.
  4. Когда работа над веткой release завершается, она сливается с ветками develop и main.
  5. Если в ветке main обнаруживается проблема, из main создается ветка hotfix.
  6. Когда работа над веткой hotfix завершается, она сливается с ветками develop и main.

Правила именования и создания веток feature

Ветка под одно (большое) логическое изменение. Формат для веток <type>/<short-body>. Тип аналогичен тому же в коммитах, а <short-body> представляет собой короткое описание назначения ветки в kebab-case стиле.

Примеры хороших названий:

  • feat/add-avl-tree
  • ci/add-klint

После одобрения пулл реквеста, ветка удаляется. А новая функциональность разрабатывается в новой ветке.

Именование веток hotfix

Формат для веток hotfix/<short-body>. Где <short-body> представляет собой короткое описание назначения ветки в kebab-case стиле.

Ветка hotfix создается только из ветки main