Skip to content

git_practices.md

Latest commit

 

History

History
101 lines (59 loc) · 5.64 KB

git_practices.md

File metadata and controls

101 lines (59 loc) · 5.64 KB

Формат сообщения коммита

1. Заголовок

  • Содержит краткое описание изменений.

  • Ограничено 50 символами или меньше.

  • Написано в повелительном наклонении (например, «Исправить», «Добавить», «Обновить»).

  • Без точки в конце.

Пример: fix(ui): resolve issue with button alignment

2. Тело (необязательно)

  • Предоставляет дополнительные сведения о коммите.

  • Объясняет что, почему и иногда как были внесены изменения.

  • Переносится по 72 символам на строку для лучшей читаемости.

Типы коммитов (стандартные коммиты)

Используйте префикс для обозначения назначения коммита:

Тип Описание Пример
feat Вводит новую функцию feat(auth): добавлен вход пользователя
fix Исправляет ошибку fix(ui): разрешено перекрытие кнопок
chore Нефункциональные изменения (например, обновления зависимостей) chore: обновлены зависимости
docs Изменения в документации docs: обновлён README
refactor Рефакторинг кода без функциональных изменений refactor: оптимизирован запрос
test Добавление или изменение тестов test: добавлены модульные тесты для входа
style Изменения стиля кода (например, форматирование) style: исправлены отступы
perf Улучшения производительности perf: улучшена стратегия кэширования
build Изменения в процессе сборки или инструментах build: добавлена конфигурация CI/CD
sec Улучшение принципов безопасности sec: изменён алгоритм хеширования на sha512

Рекомендации по написанию сообщений для коммитов

1. Используйте императивный стиль

Пишите сообщения для коммитов так, как если бы вы отдавали команду коду выполнить какое-либо действие.

  • ✅ исправить: исправлена ​​опечатка в панели навигации
  • ❌ исправлена ​​опечатка в панели навигации

2. Делайте атомарные коммиты

Каждый коммит должен представлять одно логическое изменение. Избегайте объединения несвязанных изменений в один коммит.

  • ✅ Отдельные коммиты для исправления ошибки и добавления новой функции.

  • ❌ Один коммит для исправления ошибки и обновления документации.

3. Избегайте общих сообщений

Общие сообщения, такие как «обновить код» или «исправить проблему», не передают осмысленной информации. Будьте описательными, но краткими.

4. Не добавляйте точки

Избегайте использования точек в конце сообщений коммитов. Они излишни в коротких, описательных заголовках.

5. Используйте единый стиль

Следуйте стандартному руководству по стилю для всех сообщений коммитов в команде или организации.

6. Избегайте сообщений коммитов типа:

  • "WIP" (Работа в процессе): Вместо этого используйте черновики запросов на слияние.

  • "Исправлено": Четко укажите исправление.

  • "Временные изменения": Избегайте фиксации временного или отладочного кода.

Примеры хороших сообщений коммитов

Только заголовок

feat(dark-mode): реализован темный режим для панели мониторинга

Заголовок с телом

fix(validation): решена проблема с проверкой электронной почты

Ранее логика проверки электронной почты не обрабатывала определенные крайние случаи
(например, электронные письма с символом '+'). Обновлено регулярное выражение для корректного сопоставления
действительных адресов электронной почты.