IT Загрузка..
IT Загрузка..
Читать в Telegram

Conventional Commits: стандарт написания коммитов

IT Загрузка..

Мы просто и по делу рассказываем про ИИ-инструменты для работы: сравнения, пошаговые гайды, бесплатные альтернативы и реальные сценарии применения. Помогаем выбрать между ChatGPT, Gemini, Claude, локальными моделями и десятками узкоспециализированных сервисов — от дизайна и HR до аналитики и SEO. Меньше хайпа, больше практики и экономии времени каждый день.

Открыть в TelegramДругие публикации
conventional commitsкоммитыsemantic versioning

Conventional Commits — это соглашение о том, как оформлять сообщения коммитов в Git. Его цель простая: сделать историю изменений понятной и полезной не только для разработчиков, но и для CI/CD, changelog-генераторов и систем версионирования.

Базовый формат такой:

type(scope): short description

Примеры:

  • feat(auth): add OAuth login
  • fix(api): handle timeout error
  • docs(readme): update installation guide
  • refactor(core): simplify cache logic

Зачем нужен Conventional Commits

  • Понятная история Git — по коммиту сразу видно, что изменилось
  • Автоматизация релизов — удобно для semantic versioning
  • Генерация changelog — список изменений можно собирать автоматически
  • Упрощение code review — меньше хаоса в истории проекта
  • Единый стандарт в команде — особенно важно в больших репозиториях

Основные типы коммитов

  • feat — новая функциональность
  • fix — исправление бага
  • docs — изменения в документации
  • style — форматирование, пробелы, без логики
  • refactor — переработка кода без изменения поведения
  • test — добавление или изменение тестов
  • chore — служебные задачи: зависимости, конфиги, сборка
  • build — изменения, влияющие на сборку
  • ci — изменения в CI/CD

Как это связано с versioning

Стандарт хорошо работает с Semantic Versioning:

  • fix → PATCH
  • feat → MINOR
  • BREAKING CHANGE → MAJOR 🚨

Пример:

feat(api): change user response format

Если изменение ломает обратную совместимость, это указывают явно:

feat(api)!: remove v1 endpoints

или в теле коммита:

BREAKING CHANGE: v1 API removed

Практические правила

  • Пишите кратко и по делу
  • Используйте английский или один язык на весь проект
  • Не смешивайте несколько изменений в один коммит
  • scope указывайте, если он реально помогает
  • Формулируйте описание как действие: add, fix, remove, update

Типичные ошибки

  • update code — слишком размыто
  • fix — без пояснения, что именно исправлено
  • один коммит = и багфикс, и рефакторинг, и новые фичи
  • отсутствие единого стандарта в команде ⚙️

Когда особенно полезно

  • в командной разработке
  • в open-source проектах
  • при частых релизах
  • если используются GitHub Actions, release-боты, semantic-release

Conventional Commits — это не просто “красивые сообщения”, а инструмент порядка, автоматизации и предсказуемых релизов. Один внедрённый стандарт часто экономит часы на разбор истории изменений и подготовке релизов ✅

👀 В конце дня особенно полезно держать под рукой хорошую подборку каналов про IT — с практикой, инструментами и актуальными подходами.

🗣 Подборки каналов 🧠 Каталог ботов и приложений 🗺 Навигация

Читайте так же