Вклад

Правила коммитов

Сообщения коммитов должны быть понятными без контекста и отражать одну логически завершенную правку (или тесно связанный набор изменений). Избегайте заголовков вроде «Update», «Some update», «Fix» без уточнения, что именно изменилось.

Формат

Рекомендуется формат Conventional Commits:

<тип>[(область)]: <краткое описание>
  • Тип (часто используемые): feat — новая возможность; fix — исправление ошибки; refactor — перестройка без смены поведения; docs — только документация; ci — CI/CD и скрипты пайплайна; test — тесты; build — CMake, зависимости, сборка; chore — прочее обслуживание (без функциональных изменений); style — форматирование, пробелы, без смысловых правок в коде.
  • Область — необязательна; указывает подсистему, например ci, cmake, genetic, examples. Несколько областей допустимы через запятую: feat(ci,examples): ….
  • Описание — в повелительном наклонении («добавить», «исправить», add, fix), без точки в конце первой строки, по возможности до ~72 символов.

Примеры:

fix(cmake): корректная передача флагов в подпроект
docs: описать установку зависимостей для Debian 13
ci: расширить матрицу ОС в GitLab CI

При необходимости после пустой строки добавьте тело коммита: мотивация, детали, ссылки на issue/MR (Closes #…, See …). Для несовместимых изменений явно укажите это в теле или префиксе BREAKING CHANGE:.

Язык заголовка — английский.

Что не делать

  • Не коммить временные файлы, секреты и локальные настройки, которые не должны быть в репозитории (см. .gitignore).
  • Не объединять в одном коммите несвязанные изменения «просто чтобы запушить» — удобнее ревью и откат по git revert.

Запросы на слияние (MR)

Порядок создания MR, назначение проверяющих, ревью, доработки, вливание и работа с ветками описаны в MergeRequests.md.

Начальные шаги

Полезные примечания для разработчиков можно найти в документе HACKING.md.

В дополнение к вышесказанному, если вы используете файл пресетов в соответствии с инструкциями, вам НЕ следует проверять его в системе контроля версий, как предлагает документация CMake.

Ряд файлов Markdown синхронизирован между репозиториями Generator, Graph и Parameters (в частности разделы BUILDING.md про пресеты и новые исходники в CMake, CI_PIPELINE.md, CI_SCRIPTS.md, дополнительные пункты в docs/README.md). При правках сохраняйте одинаковую структуру и формулировки во всех трех репозиториях, если изменение не относится только к одному проекту (имена пакетов, REPO_NAME / Docker, имя PDF).

Другие языки: English