Лучшие способы написания сообщений Git Commit: как у профессионалов

Когда разработчик возвращается назад во времени, чтобы найти что-то, над чем он работал шесть месяцев назад, часто он не понимает, почему он сделал этот конкретный коммит, и единственная причина этого в том, что он не следовал правильному способу написания сообщения коммита.

\ Существуют стандарты сообщений коммитов, которым следуют разработчики по всему миру, и хорошо следовать популярным стандартам, чтобы когда вы вернетесь через значительное время или кто-то другой посмотрит на ваши сообщения коммитов, они не выглядели бы нелепо!

\

\ Команды должны сначала определиться с соглашением о сообщениях коммитов, которое определяет историю контроля версий продукта, который они создают.

\ Отличное сообщение Git коммита должно иметь правильный стиль, содержание и метаданные.

\ Известный Git коммит следует этому соглашению:

<type>(<scope>): <message>

\ <type> может быть одним из следующих:

• feat для новой функции.
• refactor для рефакторинга производственного кода, например, переименования функции.
• docs для изменений в документации.
• fix для исправления ошибки для пользователя.
• perf для улучшения производительности.
• style для изменений форматирования, отсутствующих точек с запятой и т.д.
• test для добавления отсутствующих тестов, рефакторинга тестов.
• build для обновления конфигурации сборки, инструментов разработки или других изменений, не имеющих отношения к пользователю.

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

\ Область действия (scope) является необязательной, а часть сообщения должна включать однострочное утверждение, не более 72 символов, чтобы подвести итог, для чего предназначен коммит.

\ Многие разработчики также используют сообщение в качестве строки темы и добавляют тело; это, по сути, описание коммита, но однострочное сообщение коммита предпочтительнее, если вы можете понять контекст (что и почему коммита). Если коммит требует более подробного описания, которое нельзя объяснить в одной строке, тело коммита всегда необходимо.

\ Вы также можете использовать такие инструменты, как Glitter или Commitizen, для стандартизации ваших сообщений коммитов.

\ Не только это, вы также можете задаться вопросом, существует ли инструмент, который проверяет ваше сообщение коммита и выдает ошибку, если оно не соответствует рекомендациям. Commit lint - один из них. Он помогает вашей команде придерживаться соглашения о коммитах.

\ Часто эксперты отрасли используют свой тикет JIRA или Click Up в качестве сообщения коммита, чтобы все можно было связать или отследить в любое время, и кодовая база оставалась поддерживаемой для будущих разработчиков.

\ Некоторым командам также нравится добавлять эмодзи в свои сообщения коммитов. Я составил список эмодзи и их соответствующих значений. Вы можете ознакомиться с ним здесь.

\ В конечном счете, важно, чтобы ваше сообщение коммита было осмысленным и не вводило в заблуждение ваших коллег-разработчиков или будущих разработчиков относительно того, что представляет собой конкретное изменение.

\ Если вы хотите узнать больше о традиционных коммитах, семантических коммитах или практиках, которым следует отрасль, вот некоторые ресурсы для вас:

1. Традиционные коммиты
2. Семантические коммиты
3. Как писать сообщение коммита от CBeams

\