Комментарии 15
Я предпочитаю называть это как git коммиты.
МГИМО финишд?
На практике, по крайней мере у меня, не работает.
Из опыта в последних двух компаниях:
1. На прошлой: Когда ты работаешь со своей веткой, то сам себе выбираешь формат, который понятен именно тебе. Там может быть и помодульно, и тупо 'rebase' или 'daily fix', этого ни кто не увидит. В процессе можешь откатится куда угодно. Когда закончил работу, сквошишь всё в один коммит с названием тикета.
2. На текущей: Название коммита - по шаблону `{ticketName} - {ticketTitle}`. Коммиты накатываются через git commit --amend (хотя squash тоже работает).
В обоих случаях - есть принятые правила в компании. Всех промежуточных коммиты, по окончанию работы, нигде больше не будет, никого не интересует твой личный информационный мусор.
Тоже чаще всего работаю по первому варианту. Через --amend - только если для себя что-то делаю.
Обычно так же, свободный формат до пуша мерж реквеста, перед пушем что-то типа git rebase -i HEAD~4 и squash с более цивильным описанием.
Согласен с вашим комментарием. Хочу дополнить, что в неидеальном мире иногда не создаются сабтаски под мелкий рефакторинг, например, и встречается такая структура иногда `{ticketName} - {ticketTitle} // {whatWasDone}`. Либо задача бьется на сабтаски, а в процессе выясняется что они сильно связаны (либо просты, чтобы тратить время на переключение контекста) и делают их де-факто в одной ветке. Опять же, это костыль о разумности, балансе и управлении разделением на подзадачи, который в идеальном мире вроде как не нужен.
Немного притомило это бездумное повторение Conventional Commits, которое плохо приживается в командах, потому что внезапно выясняется, что коммит делает какую-то фичу которая например размазана на кучу скоупов, да ещё этот бесполезный "fix:" говорящий что масло-то, оказывается, масляное, после чего читаешь всякую фигню типа "[fix] small fix on orders view", "fix: orders controller fix" и прочее ехал фиксик через фиксик. А заголовок коммита очень сильно ограничен, туда и просто текст "что делал" нормально не влезает. Ну и, конечно, все почему-то ленятся написать что круто было бы где-то и номер задачи тоже писать (половина тоже любит делать это впереди). А потом ещё как-то нужно отсматривать всю эту портянку, а то что написано в тушке далеко не всегда удобно читать (--oneline или всякие гит-клиенты с гуями схлопнут это). Ну и, конечно, текст такого коммита (его ПОЛЕЗНАЯ и СОДЕРЖАТЕЛЬНАЯ часть) будет не видна во всяких полуклиентах встроенных в IDE, потому что там места ещё меньше.
Поэтому в первую очередь пишется, а что вообще вы там делали, плюс номер задачи в трекере. И только потом всякие ваши хотелки, костыли, полутеги и прочий жир.
И такие коммиты, где написано что делалось и нафига (номер таски) отлично потом выгружаются вполне себе штатными командами типа `git shortlog --no-merges HEAD --not ${prev_tag}` в красивый change log к релизу, без лишних скриптов, костылей и мусора. И номера тасок в этом красивом чейнджлоге, внезапно, превращаются во всяких гитхабах в классные прямые ссылки на таски.
Вместо того чтобы костылить эти ужасы, лучше освоить штатные фичи гита или хотя бы поставить git-клиент, например GitExtensions, который умеет в кучу интеграций (в т.ч. переходы по номеру таски прямо в трекер, причём в любой, в т.ч. в жиру) и в котором сразу будет понятно, почему лапша в тасках - это не для людей, а раз это не для людей, то внедрять и пользоваться этим будет боль, страдания и сопротивление
номертикета: заголовок тикета
универсально подходит к любому коммиту
Странно
Инструкция как писать стандартизированные комментарии к коммитам (git commit)