Стиль именования коммитов

[ZmeeeD]

> старайтесь использовать хороший стиль именования коммитов в своих проектах
В командных проектах есть договорённость (номер тикета, описание, зависимости)
А в личных точно по настроению… бывают и не приличные :))

[monolithed]

У меня на этот случай есть небольшой хук, который добавляет название ветки к сообщению коммита.

[MegaMufa]

Спасибо. Очень вовремя. Раньше слабо задумывался о том, как оформлять сообщения к комитам.
А сейчас кодовая база разрослась, надо наводить порядок. А тут как раз ваша статья.

[Singerofthefall]

Не согласен с пунктами про большие буквы, знаки препинания и прошедшее время.

При всей лаконичности, сообщения должны быть написаны на нормальном языке — например вот тут у вас времена намешаны, в результате если просто прочитать это сообщение, то может показаться, что вы улучшили UI, а теперь просите кого-то заменить twitter-bootstrap.css на pure.css:

replace twitter-bootstrap.css with pure.css

Made UI much cleaner.

[olegafx]

В статье по этому поводу всё написано:

Предстаьте, что вы обращаетесь к Git: «Git, добавь», «Git, удали» и т.д.

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

[olegafx]

Никому ничего не навязываю. Мне удобнее писать так. От «Added» коммит понятнее не станет, потому что итак понятно, что он был в прошлом.

[ortemij]

Зачем же вы в статье прошедшее время использовали, и так же понятно, что она в прошлом написана. :)

[olegafx]

Что именно вы не сможете прочитать в такой истории?

[olegafx]

Ну так и напишите тому человеку. Мне-то вы зачем это пишете? :)

[olegafx]

Я придерживаюсь стиля, описанного в статье. Во-первых, я бы указывал конкретные «issues». А во-вторых, «fix issues» — вполне нормальная конструкция.

Fix security issues

[yul]

Вполне нормальная конструкция для указания того, что нужно исправить. Можно еще please добавить ;)
Я использую настоящее время в названии тикета и прошедшее в коммите.

[Singerofthefall]

В статье по этому поводу всё написано:

Я не говорю, что не заметил вашего обоснования этих советов в статье. Я говорю, что я лично с ними не согласен, и привожу свое мнение. Я не хочу представлять, что я обращаюсь к Git. Git Не будет читать эти сообщения, их будут читать другие разработчики. Соответственно, я считаю, что человеку удобнее будет и понятнее читать

Fixed a critical issue in module.cpp; please refer to readme.txt for more information.

а не

fix(module.cpp) critucal issue

Additional info in readme.txt.

Заметьте, я не призываю писать в commit message эссе на 10 листов. Но можно одновременно писать и кратко, и грамотно — с нормальными временами и знаками препинания.

[ABBAPOH]

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

[bazzilic]

Это не настоящее время, а императив. Почувствуйте разницу между «fix issue» и «fixes issue».

[BasicWolf]

Полностью согласен с Вами по обоим пунктам. Начинаю с прописной буквы и всегда пишу в прошедшем времени.

[Memph1s]

Я просто оставлю это здесь
tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

[nshopik]

stopwritingramblingcommitmessages.com/

[astudent]

Думаю, Вы путаете прошедшее время и третье лицо.

[tibalt]

может пассивный залог?

small bug (is) fixed — маленький баг поправлен

п.с. кстати, я именно так и пишу и считаю, что разговаривать с гитом — тупо

[Goodkat]

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

[olegafx]

У хорошего коммита, как и у хорошего комментария, должна быть одна зона ответственности. Если вы в одном коммите меняете разные модули, классы, то это бардак (по моему мнению). В git есть замечательные теги, которые можно применять к коммитам. И потом сравнивать уже по тегам.

[relgames]

Один коммит — на одну логическую единицу. Не важно, в одном файле или разных.

[jekaby]

Коммит, в идеале, атомарное изменение.
Но, при мерже не минорных правок, иными словами, при мерже feature branch в main branch не хочется или не всегда хочется иметь огромное число коммитов. Поэтому, мерж делаю со сквошем.
В итоге, в рамках main branch не видно этой красоты.

[Rustam]

Не знаю, как другие делают, но у меня комментарий к коммиту отвечает на вопрос: что я сделал в данном коммите. Поэтому я все пишу в прошедшем времени. И использование/неиспользование заглавных букв — дело привычки. Тут уже все от принятых стандартов зависит.

[Memph1s]

Что вы сделали я могу в самом коммите посмотреть, комментарий должен объяснять ЗАЧЕМ вы это сделали. Очень сильно это помогает в командах, где работают в разных часовых поясах.

[Rustam]

В смысле зачем? Не писать, что я реализовал фичу #X, но написать: я реализовал фичу #X, потому что она стояла у меня в задачах?

[Memph1s]

#X — Feature added

This feature helps to make things
easier in workflow and reduces
code complexity.

[Rustam]

Зачем писать это в коммите, если это есть в баг-трекере?

[Memph1s]

Два момента:

1. Мой пример не совсем правильный. Фича может состоять из нескольких коммитов, и каждый должен быть прокомментирован, почему конкретное изменение сделано.

2. Гораздо удобнее сделать git log вместо того, чтобы лезть в браузер и искать этот тикет.

[FINTER]

Ну можно посмотреть на это не со стороны разработчика, а со стороны мэйнтейнера.
Для него коммит отвечает на вопрос: «Что произойдет, если я пульну или смержусь с ним?»

Хотя лично я пишу в прошедшем времени.

[hoxnox]

Помнится Offenso предлагал необычный способ навести порядок в коммитах.

[RomanNikitin]

Самое главное — это указывать issue (через #ISSUE_ID) к которому относится коммит. Очень полезно при серьезной работе на github.
Остальное — мелочи.

[hoxnox]

Не согласен про мелочи. Так и представляю:

$> git log --pretty=oneline

fd6ab367a690e2dd438e3282ea9d2c8415f2296a #54!!!
afd843c40a9e5df6663dbf122f673d1c2eea77bf #42, #43 and #35
7ad7a34bef74124100465eac02241a0484b2f4db #31, #32

А так да, многие системы управления проектами подхватывают ссылки на коммиты, если указывать номер тикета.

[RomanNikitin]

Да, кстати такое я вот тоже видел :)
Но все же стараюсь писать:

Working on someshit (#31)
— added new blah
— removed few blah
— …
— profit!

[Memph1s]

Гит прекрасен тем, что позволяет полноценно работать и без интернета. Не спорю, указывать номер полезно, но чем вам поможет номер бага/тикета, когда вы не можете его прочитать? Более того, номер тикета — это несколько дополнительных кликов в браузере. Комментарий, который объясняет, для чего сделаны изменения, сохранит вам время и нервы.

[RomanNikitin]

Я понимаю. Но в начале статьи висит иконка github — вот я и говорит в рамках github (активно использую его для работы).

[relgames]

Комментарии в настоящем времени читаются довольно странно. Коммит — это фиксация того, что мы сделали.

[Dair_Targ]

А ещё можно не мудрствовать, а просто вписывать номер задачи.

[tenzink]

Я бы к этому добавил краткое описание. Полезно, чтобы другие члены команды в общих чертах представляли что произошло без необходимости обращатсься к трекеру. Например:
[SDK-513] Added compile-time check that ... supports ...
[ABC-1231] Enabled progress indication
[ABC-1311] Deleted unused code
Теперь окинув взглядом историю можно быстро оценить что произошло за последнее время.

[Andy_Ion]

Пишу имя тикета в JIRA, затем текст коммита в прошедшем времени. Мне кажется, так удобнее читать :)

[gomzyakov]

Совсем недавно GitHub обновил дизайн, сосредоточившись, как это сейчас принято, на контенте. В контексте гихаба (а им, я уверен, пользуются многие хабровчане), именование коммитов в прошедшем времени выглядит гораздо логичнее, чем в настоящем:

[m-haritonov]

Я стараюсь придерживаться следующего стиля: «Номер задания в багтрекере или затронутая область подсистемы (пространство имён): описание изменений». Пространство имён указываю либо общее для группы изменений либо пишу несколько подобных записей в одном коммите (если так вышло, что в одном коммите приходится фиксировать, например, несколько изолированных друг от друга изменений и изменение, затрагивающее файлы всех этих изолированных изменений). В целом, стараюсь фиксировать изолированные изменения по отдельности (если речь не идёт о черновой стадии работы над индивидуальным проектом). Описания стараюсь писать безотносительно времени (описывая изменение как факт).

Примеры нескольких коммитов:

1. ESH-419: тут либо дублирую заголовок из багтрекера либо перефразирую его в более подходящий вид (если заголовок, заданный автором задания в багтрекере не совсем точно соответствует вносимым изменениям)
2. components.shop.basket: добавление поддержки товара типа «ноутбук» в корзине покупок
3. components.shop: исправление ошибки взаимодействия корзины покупок и списка товаров

[StreetStrider]

В паре личных проектов использовал следующую нотацию:
В начале в квадратных скобках ставится модификатор действия:
+: added
— : deleted
*: modified (любая модификация, кроме фикса, которая хорошо описывается как «изменение»)
f: fixed
Далее идёт объект, над которым совершалось изменение (без глагола).
[+] Tests for component X.
Многострочные комментарии не использовались, так как любое слишком крупное изменение разбивалось на два коммита.
После объекта идёт опциональный параметр, который записывается как [/]. Это индикатор т.н. partial-коммита, который не переводит проект в целостное состояние. Обычно, такие коммиты создаются в пылу кодинга, а потом подчищаются с помощью amend / rebase на свежую голову.
В конце обязательно ставится точка.
Мерж-коммиты, как правило, содержали описание основных фич, которые были смержены.
В целом, концепция была неплохая, но и без неё тоже неплохо работается. Тем более, если работаешь над проектом один. Описание коммита важно, но содержание важнее.
Сейчас в личных проектах пользуюсь нотацией «по настроению».

[Zelgadis]

Action. short desc. issue#

Fix. internal error during on-boarding. #1192
Feature. add pckry everywhere. #1193 #1194
Fix. too many requests to facebook during usual tasks. #1201 [WIP]

[ivan_kolmycheck]

Я предпочитаю писать комментарии к коммитам в прошлом времени, но качественно.

[mocksoul]

action<. short desc>
<[fix/ref] issue id1: what was made for issue1>
<[fix/ref] issue idN: what was made for issueN>

short desc — до 60 символов
action — только в прошедшем времени:

В теории может быть ещё длинное описалово посередине с несколькими абзацами, но подобные вещи стараюсь избегать.

Я не пишу это в гите. И не работаю в гите. Но мои проекты на гитхабе)

система контроля версий может поменятся — история должна быть читабельной.
багтрекер может поменятся — хорошо если с сохранением тасков.
интернета может не быть — никаких ссылок

[masai]

Мой комментарий запоздал всего на пару лет, но всё же напишу. :) Тут много спорили о том, в прошедшем времени писать или в настоящем. Сами разработчики Git рекомендуют использовать императивный стиль:

Describe your changes in imperative mood, e.g. «make xyzzy do frotz» instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour.

Но каждый, конечно, решает сам. Хороший комментарий (пусть даже в будущем времени) будет лучше плохого, хоть и написанного по всем правилам.