Пять полезных советов при составлении коммит сообщения

Итак, Вы готовы сделать свой великолепный коммит, который, безусловно, делает код чуточку лучше, либо фиксить какой-то баг, а может, Вы и вовсе решили поменять переходы строк на Windows/Unix-Style? Естественно, Ваш код безупречен и достоин всевозможных похвал! Браво! Достойно ли Ваше сообщение Ваших трудов? Смогут ли потомки разобрать, что Вы сделали через месяц? Через год? Десять лет?

1. Первая строка должна составлять 50 символов или меньше и завершаться пустой строкой (\n\n). Для редактора Vim существует множество плагинов для синтаксиса, авто-отступов и по типу файлов, которые могут очень легко помочь в этом.
2. Добавьте эту строчку в свой файл .vimrc для проверки орфографии, а также авто-перехода строки в рекомендуемые 72 символа:
   autocmd Filetype gitcommit setlocal spell textwidth=72
3. Никогда не используйте флаги для сообщения -m <msg> / --message=<msg>
   Это ставит вас в рамки для описания внесенных изменений, вам приходится умещать своё сообщение в маленькую строчку, и это мало похоже на целую страницу в истории вашего кода:
   git commit -m "Fix login bug"
   Более полезное и информативное сообщение может выглядеть так:
   
   

   Перенаправление пользователя после авторизации

   chyrius.com/path/to/relevant/card

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

   * Сохранение пути в переменной сессии
   * Перенаправление на сохраненный путь после удачной авторизации

4. Ответьте на несколько вопросов:
   
   1. Почему данное изменение необходимо?
      Этот вопрос расскажет вашим потенциальным pull request ревьюверам, что именно в коммите, позволит им проще распознать несвязные изменения.
   2. Как коммит решит проблему?
      Опишите простым языком ваши изменения:
      «Реализовано красное-черное дерево для увеличения скорости поиска» или «Удален пакет зависимости <такой то>, который вызывал проблему <описание проблемы>».
      Если ваши изменения очевидны, то этот вопрос не обязателен.
   3. Вызывают ли изменения побочные эффекты?
      Пожалуй, один из самых важных вопросов, он может указать на проблему множества изменений в одном коммите или ветке. Одно или два связных изменения в коммите, это нормально, но если их 5 или 6, это означает ваш коммит делает слишком много 🙁

      Вы со своей командой должны заранее договориться, сколько изменений максимально умещается в один коммит/ветку.

5. Включите в ваше сообщение линк на баг/улучшение/дискуссию вашего проекта. Полный линк будет более полезен, чем только номер бага, либо название темы обсуждения. Обычно линки вставляются после резюме на третьей строчке.

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

Отдельное спасибо Tim Pope, который попытался установить новый стандарт для коммит сообщений.

Дополнительное спасибо создателю Git и убежденному стороннику хороших коммит сообщений, Linus Torvalds.