Как стать автором
Обновить

Комментарии 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 слов о том, что сделано" и жить стало чуть чуть легче =)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории