[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-git-chto-takoe-conventional-commits":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":17,"progress":18,"seo":19},1339,"chto-takoe-conventional-commits",44,"git","Git","📦","Что такое Conventional Commits?","Conventional Commits — это спецификация для стандартизации формата коммит-сообщений, обеспечивающая единообразную историю, автоматическую генерацию changelog и определение следующей версии по типам коммитов.\n\n### Формат\n\n```\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\n[optional footer(s)]\n```\n\nПримеры:\n\n```\nfeat(auth): add JWT token refresh endpoint\n\nfix(payment): correct rounding error in tax calculation\n\nrefactor(user-service): extract validation logic to separate class\n\ndocs: update README with new build instructions\n\nchore(deps): upgrade Spring Boot to 3.3.0\n```\n\n### Типы (types)\n\n| Тип | Назначение | Влияние на версию |\n|---|---|---|\n| `feat` | Новая функциональность | MINOR (1.x.0) |\n| `fix` | Исправление бага | PATCH (1.0.x) |\n| `docs` | Изменения в документации | -- |\n| `style` | Форматирование, без изменения логики | -- |\n| `refactor` | Рефакторинг (не fix и не feat) | -- |\n| `test` | Добавление\u002Fисправление тестов | -- |\n| `chore` | Сборка, CI, зависимости | -- |\n| `perf` | Улучшение производительности | PATCH |\n| `ci` | Изменения в CI\u002FCD конфигурации | -- |\n| `build` | Изменения в системе сборки | -- |\n| `revert` | Откат предыдущего коммита | -- |\n\n### Breaking Changes\n\nНесовместимые изменения обозначаются двумя способами:\n\n```\n# Способ 1: восклицательный знак после типа\nfeat(api)!: change response format to JSON:API\n\n# Способ 2: футер BREAKING CHANGE\nfeat(api): change response format\n\nBREAKING CHANGE: response format changed from custom JSON to JSON:API.\nAll clients must update parsers.\n```\n\nBreaking change увеличивает MAJOR версию (x.0.0).\n\n### Связь с Semantic Versioning\n\n```\nfix: ...              -> v1.0.1  (PATCH)\nfeat: ...             -> v1.1.0  (MINOR)\nfeat!: ...            -> v2.0.0  (MAJOR)\nBREAKING CHANGE: ...  -> v2.0.0  (MAJOR)\n```\n\n### Автоматизация\n\n```bash\n# Установка commitlint (проверка формата)\nnpm install -g @commitlint\u002Fcli @commitlint\u002Fconfig-conventional\n\n# Использование с Husky (git hooks)\nnpx husky add .husky\u002Fcommit-msg 'npx commitlint --edit $1'\n\n# Автогенерация changelog\nnpx conventional-changelog -p angular -i CHANGELOG.md -s\n\n# Автоматический релиз с semantic-release\nnpx semantic-release\n```\n\n### Ключевые моменты\n\n- Conventional Commits — это спецификация, а не инструмент. Валидация выполняется через commitlint или git hooks\n- Формат позволяет автоматически определять тип версии (MAJOR\u002FMINOR\u002FPATCH) на основе коммитов\n- `scope` — необязательный, обычно указывает модуль или область изменений\n- Body и footer отделяются от заголовка пустой строкой\n\n### Частые ошибки\n\n- Писать описание с заглавной буквы — по конвенции начинается со строчной\n- Ставить точку в конце заголовка — не ставится\n- Превышать 72 символа в заголовке — затрудняет чтение в `git log`\n- Использовать неправильный тип: `fix` для рефакторинга или `feat` для исправления бага\n- Забывать про `BREAKING CHANGE` при несовместимых изменениях\n\n### Как используется в 2026\n\n- Conventional Commits — стандарт де-факто в open-source и многих enterprise-проектах\n- `semantic-release` и `release-please` автоматически создают релизы, теги и changelog на основе коммитов\n- AI-ассистенты в IDE автоматически предлагают коммит-сообщения в формате Conventional Commits\n- Интеграция с Jira\u002FYouTrack: номер задачи в scope или footer автоматически связывает коммит с задачей\n\n> **На собеседовании:** покажите знание формата: `type(scope): description`. Перечислите основные типы (feat, fix, docs, refactor, chore) и их влияние на версию. Ключевая связь: Conventional Commits + Semantic Versioning = автоматические релизы. Упомяните инструменты: commitlint, semantic-release, Husky.","","middle",[7,15,16],"best-practices","ci-cd",[],null,{"title":20,"description":21,"ogTitle":22,"ogDescription":23,"keywords":24,"schemaAnswer":34,"featuredSnippetReady":35},"Что такое Conventional Commits — Gymterview","Conventional Commits: формат type(scope): description, типы (feat, fix, docs, refactor), связь с Semantic Versioning, Breaking Changes, автоматизация релизов.","Conventional Commits: формат, типы и автоматические релизы — Gymterview","Формат type(scope): description. feat -> MINOR, fix -> PATCH, BREAKING CHANGE -> MAJOR. Автоматизация через semantic-release.",[25,26,27,28,29,30,31,32,33],"Conventional Commits","коммит-сообщения","feat","fix","Semantic Versioning","commitlint","semantic-release","changelog","собеседование","Conventional Commits — спецификация формата коммит-сообщений: type(scope): description. Типы: feat (MINOR), fix (PATCH), docs, style, refactor, test, chore, perf, ci, build, revert. Breaking Changes обозначаются ! после типа или футером BREAKING CHANGE (MAJOR). Связь с Semantic Versioning позволяет автоматически определять версию. Инструменты: commitlint (валидация), semantic-release (автоматические релизы), Husky (git hooks).",true]