Стандарт, который следует соблюдать при написании сообщений git commit

Ответ 1

Когда вы просто описываете, что вы сделали (в технических, но нечетких терминах, таких как "добавлена ​​функция" ), вы не добавляете много того, что Git уже хранит в фиксации. Представьте себе, что вы читаете сообщение о фиксации через некоторое время; какое резюме поможет вам самому запомнить/передать другим разработчикам суть этого изменения?! Точное содержание зависит от вашего проекта и процессов, но я считаю, что это хорошая рекомендация.

Поэтому, прежде всего, добавьте контекст (почему, а не как) с вашим сообщением фиксации (например, "frobnize message to enable persistence" ) вместо "добавлена ​​функция frob()" ). Это больше усилий (вы должны размышлять и думать), но это стоит гораздо больше.

Если вы хотите узнать больше об этой теме, там будет много информации, например в этой статье в блоге Питера Хаттерара или этот смешной слайд.

Ответ 2

Модель 50/72 кажется хорошей практикой. то есть... первая строка должна быть длиной 50 символов и должна быть сервером в качестве заголовка. Вслед за пробелом второй набор строк должен быть обернут в 72 символа и должен служить резюме. Вот вопрос SO: Git Commit Messages: 50/72 Форматирование, который обсуждает то же самое.

Вот несколько исчерпывающих замечаний по теме:

• Git Зафиксировать хорошую практику
• Заметка о Git Фиксировать сообщения
• Собственные Git Фиксированные сообщения и Элегантная история Git

Ответ 3

Git уже знает, какие файлы вы модифицировали в фиксации, бесполезно указывать его в комментарии. Просто скажите, например, "исправлена ​​ошибка заполнения" или "добавлено меню на боковой панели". Дайте понять, что это.