[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-conventional-commits::ru":3,"gloss-cluster-conventional-commits::ru":26,"gloss-next-conventional-commits::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"conventional-commits","dev-tools","Conventional Commits (соглашение о коммитах)","Conventional Commits — соглашение о записи сообщений коммитов в машиночитаемой форме: тип, необязательная область и короткое описание — `fix(auth): отклонять просроченные refresh-токены` — плюс необязательные тело и футер для ломающих изменений и ссылок на задачи. Ценность не в аккуратности ради аккуратности. Как только сообщения несут тип, инструменты могут сгенерировать список изменений, определить следующую семантическую версию и запустить релиз без того, чтобы кто-то вёл эти сведения вручную. Именно это соответствие и распространило соглашение: исправление подразумевает патч-версию, функция — минорную, пометка о ломающем изменении — мажорную, и номера версий перестают быть решением, принимаемым на глаз в момент релиза. История становится и удобной для поиска: отфильтровать год коммитов до тех, что меняли поведение, а не форматирование, — по-настоящему полезная операция во время инцидента. Две оговорки не дают соглашению стать обрядом. Правило, навязанное линтером сообщений, но не подкреплённое ревью, порождает безупречно оформленные сообщения ни о чём: `fix(api): исправлен баг` удовлетворяет проверке и не помогает никому, а через полгода важнее всего именно описание. И тип должен отражать то, что изменение делает с потребителями, а не самоощущение автора: рефакторинг, меняющий ответ API, является ломающим изменением, каким бы внутренним он ни казался. Командам, схлопывающим пул-реквесты, стоит помнить, что в историю попадает сообщение схлопывания — соглашение должно соблюдаться именно там.","Conventional Commits делают сообщения машиночитаемыми, а список изменений и версию — производными; и два способа превратить соглашение в обряд.",null,[11,14,17,20,23],{"slug":12,"name":13},"ci-cd","Непрерывная интеграция \u002F непрерывное развёртывание (CI\u002FCD)",{"slug":15,"name":16},"pull-request","Pull Request (PR)",{"slug":18,"name":19},"semantic-versioning","Семантическое версионирование (SemVer)",{"slug":21,"name":22},"trunk-based-development","Trunk-Based Development (разработка на основе ствола)",{"slug":24,"name":25},"version-control","Контроль версий (Version Control)",[27,31,34,38,41,44,47,50,53,54,57,60],{"slug":28,"category":5,"name":29,"updated_at":30},"agent","Агент (Agent)","2026-08-24T02:46:36+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ai-code-assistant","AI-помощник по написанию кода",{"slug":35,"category":5,"name":36,"updated_at":37},"api-gateway","API-шлюз (API Gateway)","2026-08-24T02:46:37+00:00",{"slug":39,"category":5,"name":40,"updated_at":37},"api-versioning","API Versioning (версионирование API)",{"slug":42,"category":5,"name":43,"updated_at":30},"autonomous-agent","Автономный агент (Autonomous Agent)",{"slug":45,"category":5,"name":46,"updated_at":37},"blue-green-deployment","Blue-Green Deployment (сине-зелёное развёртывание)",{"slug":48,"category":5,"name":49,"updated_at":37},"canary-deployment","Canary Deployment (канареечное развёртывание)",{"slug":51,"category":5,"name":52,"updated_at":37},"chaos-engineering","Chaos Engineering (хаос-инжиниринг)",{"slug":12,"category":5,"name":13,"updated_at":30},{"slug":55,"category":5,"name":56,"updated_at":37},"circuit-breaker","Предохранитель (Circuit Breaker)",{"slug":58,"category":5,"name":59,"updated_at":37},"cli","Интерфейс командной строки (CLI)",{"slug":61,"category":5,"name":62,"updated_at":37},"cloud-development-environment","Облачная среда разработки (CDE)"]