engineering-playbook/docs/advanced/02-commit-standards.md

Стандарты истории: Conventional Commits и Rebase

В Enterprise-системах история коммитов должна читаться как идеальная техническая документация. Инженеры не принимают коммиты с бессмысленными сообщениями вроде "fixed bug", "wip" или "updated files".

1. Conventional Commits (Конвенция Коммитов)

Каждый коммит должен строго соответствовать формату: <type>(<scope>): <subject>

• feat: — Новая функция (от слова feature).
• fix: — Исправление бага.
• docs: — Изменения в документации.
• refactor: — Рефакторинг кода (изменение внутренней структуры без изменения внешней логики).
• chore: — Системные задачи (обновление зависимостей, правка конфигов CI/CD).

Пример правильного коммита: feat(auth): integrate Authentik SSO login endpoint

2. Чистота истории (Squash и Rebase)

Мусорные коммиты (например, "fix typo", "update again", "test") категорически не должны попадать в главные ветки (main, stage, dev).

• Squash Commit: При слиянии Pull Request всегда используйте стратегию "Squash and Merge". Это аппаратно "сожмёт" все ваши 20 мелких рабочих коммитов в один чистый, красивый коммит в целевой ветке.
• Git Rebase: Если ваша рабочая ветка сильно отстала от main (коллеги уже залили новый код), используйте git rebase main вместо git merge. Rebase аккуратно перенесёт все ваши локальные коммиты поверх самой свежей истории main, избегая генерации лишних merge-коммитов, которые запутывают граф истории репозитория.