LINUX.ORG.RU

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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)

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

руками

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

На русском

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

фу

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

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

pru-mike ★★ ()

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

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

UVV ★★★★★ ()

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

Legioner ★★★★★ ()

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

EugeneBas ★★ ()
Ответ на: комментарий от EXL

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

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

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 2)

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

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)

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

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

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

anonymous ()
Ответ на: комментарий от EXL

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

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

anonymous ()
one-line summary

more elaborate comment
(multiline if needed)

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

slovazap ★★★★★ ()

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

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

beastie ★★★★★ ()
fix ...
add ...
remove ...

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

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

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

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

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

grem ★★★★★ ()

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

filosofia ()
Ответ на: комментарий от beastie

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

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

dimgel ★★★★ ()

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

bhfq ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

+1.

Так и надо.

-1.

dimgel ★★★★ ()

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

urxvt ★★★★★ ()

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

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

Evenik ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.