Пользуюсь рекомендациями официальной книги Pro Git:

Если вы пишите сообщения к коммитам на английском языке, то хорошей идеей является использование повелительного наклонения глаголов в настоящем времени. Другими словами, пишите команды. Вместо «Added tests» или «Adding tests» используйте «Add tests».

Классика: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

git commit -am …

Как вы пишите сообщения к коммитам?

руками

На каком языке?

На русском

Пользуетесь ли правилами вроде этих?

фу

Мои сейчас похожи скорее на известный комикс

Я исхожу из принципе, что сообщения в коммите должно кратко сообщить для чего сделаны изменения при просмотре blame-а

На каком языке?

А какие варианты?

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

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

Пользуюсь рекомендациями официальной книги Pro Git

+1, либо это, либо называю согласно существующим соглашениям в компании/проекте, над которым работаю.

Как договоримся на проекте так и пишем. Всякие там ссылки на «единственно правильный способ», который жеппы ленивые притаскивают с первой страницы гугла, кто-то тоже для себя придумал. А секта свидетелей «бестпрактисов» точно стремится отключить моск не только себе, но и всем вокруг.

тут проблема: писать сообщение на каждый «чих», как-то не очень, в качестве простого решения имеет смысл задуматься о группировке (как правило своих коммитов (git rebase --interactive))

В идеале, короткие сообщения коммитов (и да, в повелительном наклонении, спасибо EXL за ссылку) группировать после rebase в один результирующий коммит. Но с rebase аккуратнее, есть много замечаний.

Вообще, есть хорошая рекомендация, кажется от Линуса: коммит должен быть как письмо в текстовом/консольном формате и по ширине и по содержанию, особенно важно наличие короткого заголовка и опционально тела письма.

Вместо «Added tests» или «Adding tests» используйте «Add tests».

Ого, прям переворачивает представление о коммитах, и волосы станут шелковистыми, и член снова стоять начнет на полвторого.

one-line summary

more elaborate comment
(multiline if needed)

Только английский. Больше ничего не нужно.

git commit -am …

CG / AM…

Если команда русскоязычная, то на русском. Описываю то, что сделано. Если сделано более одного (это плохо, но регулярно случается), то ставлю многоточие или другой знак препинания в конце первой строки и дальше пишу многострочно, пока не будут описаны все действия. Хотя иногда в запарке бывают коммиты типа «работа идёт» - но это только в ситуации, когда коммит - это промежуточный результат какой-то работы, который сам по себе неважен и к которому уже вернуться всё равно не будет иметь смысла, т.к. в этот момент всё уже слишком запуталось и словами объяснить невозможно.

git commit -am …

CG / AM…

Пойду поем.

Было ровно на бумаге, да забыли про овраги.

В общем случае коммитные сообщения мне ещё никогда при форензике не помогали. Т.я. я на них и особого внимания не обращаю. Диффы и бисект помогают, а коммитные сообщения – каждый дрочет как может.

fix ...
add ...
remove ...

Если совсем лень, то save.

• Стараюсь следовать рекомендациям проекта.

• Пытаюсь запихнуть заголовок сообщения в 72 символа.

• Если изменения не слишком тривиальные, то в теле коммита подробнее расписываю, какая проблема решена со ссылками на баги, если они уже есть, и/или коммиты после которых проблема появилась.

• Если идея изменений чужая, но долго не была доведена до конца, то ссылаюсь на незакрытый пулл-реквест.

Мои сейчас похожи скорее на известный комикс…

Так и надо.

Я следую нескольким правилам. Коммит должен выполнять одно значительное изменение, и его код должны работать, то есть компилироваться и проходить тесты — как минимум. Из этого следует все остальное. Если просто что переместил, переименовал, незначительно отрефакторил и дифф говорит сам за себя, пишу что-то однострочное. Для более сложных изменений пишу развёрнутые истории с акцентом зачем и почему. По моему опыту, хорошее разбиение на коммиты и сообщения в них помогают разбираться при ретроспективе каких-то изменений спустя годы после их внесения. Если у меня программист не может в коммиты, я его доебу и плешь выем, но пулл-реквест не заапрувлю, пока не научится.

CG / AM…

Пойду поем.

Ничё не перепутал? :)

Было ровно на бумаге, да забыли про овраги.

Не вполне понял, каким боком твой ответ к моему оффтоповому флуду, ну да ладно. :)

какое там «визуальное ограничение» на первую строку сообщения в github? 50 или 80?

Мои сейчас похожи скорее на известный комикс…

+1.

Так и надо.

-1.

Пишу нормально. Коллеги — герои комикса.

форензике

Вас ист дас?

Let me google that for you

Всем спасибо за ответы

Буду стараться не выключать мозг и учиться в естественные языки.