Comments 9
И после всех этих манипуляций и страданий в истории изменений в IDE, а ещё лучше через git shortlog --no-merges HEAD --not ${prev_release}
вам показывает что? Я просто когда вижу все эти конвеншнл [fix] #1234 fix for prev fix вместо нормального человекочитаемого текста - всегда хочу спросить у автора, а делал то ты что?
Стараюсь писать нормальный тайтл с номером задачи в конце и этого более чем хватает. В тушку могу пояснений написать. Оно отлично читается и в IDE (даже если все боковые расхлопушки максимально узкие), и как выхлоп для release notes, и в git log --oneline
, а номер задачи отлично превращается в ссылку на гитлабе или, например, в GitExtensions, которая поведёт напрямую в трекер одним кликом.
А можно добавить в алиас немного магии
report = "!me=$(git config user.email); git log --all --author-date-order --since=1 --reverse --no-merges --pretty=time --date=format:'%Y-%m-%d %H:%M:%S' --author=\"$me\""
и git report
будет вам помогать даже время трекать по таскам
Соглашусь с вами. Лично мне данный (о чем я говорит) "шаблон" коммитов нравится и кажется достаточно информативным. Вместо scope, как описано в правилах, можно писать номер задачи:
fix(#1): реализация базового функционала чего-то
Реализовано то-то и то-то в таких-то местах
Это жрёт полезное место в списке, который в IDE часто по умолчанию выглядит примерно так
И не добавляет смысла, лишь дополнительно усложняет людям жизнь. Кому-то покажется что незначительно, но на самом деле обильно разложенные везде грабли прилично так клюют мозг. Если ОЧЕНЬ хочется, можно отдельно помечать ci, docs, build fix, но нет смысла ухудшать те вещи, над которыми разработчики работают постоянно, у вас большинство коммитов будет начинаться с Fix(same-part-as-prev): Fix something.... Лучше делайте акцент на хорошо сформулированном лаконичном тексте мессаджа.
Есть куча активно пилящихся огромным количеством людей проектов, которые отлично живут без таких церемоний, при этом фичи непосредственно гита используют весьма и весьма активно. Тот же VSCode https://github.com/microsoft/vscode/commits/main
Я правильно понимаю, что оно коммитит все изменения, а не только то что я хочу (выбрать файл, выбрать строки)?
Но, это надоело и стало как-то неудобно, когда у нас есть четкое деление задач на фиксы, фичи и так далее.
А зачем вам деление на фиксы, фичи и так далее? Вот вы видите эти коммиты раздельно, и что?
вопрос с подкавыркой ;)
Ну да, еще с какой подкавыркой. В общем случае, захотелось как-то стандартизировать решение это. А деление на типы коммитов поможет определить кто, что и сколько делал. С другой стороны, можно поставить тэги на задачу, мол БАГ/ФИЧА и так далее, но тут я даже не знаю. Лично мне было бы круто видеть в истории гита не только то, что за задача была, а что именно человек делал, чтобы не лезть в хаб/лаб.
что именно человек делал
Это и должны писать в коммите, а не левые церемонии
что за задача была
это, если нужно, отлично находится по номеру задачи который будет после мессаджа (или даже в body коммита, а может даже и не один номер)
определить кто, что и сколько делал
звучит как максимально неправильная попытка пронормировать работу разработчиков. Отличный план чтобы разрабы не проект улучшали, а пасли друг друга
У нас тоже была такая система, без софтовой обвязки только. Спустя время поняли, что это ничего не дает лично нам и перешли на систему "номер таска: максимум 5-7 слов о том, что сделано" и жить стало чуть чуть легче =)
Как мы интегрировали и настроили для работы Conventional Commits в PHPStorm