Комментарии 23
даёшь статейку в топ хабра!
Стоит еще особо отметить, что использовать большинство хуков и тем более каким-нибудь скриптом сборки включать их для всех и каждого — плохая идея. Большинство хуков вызываются не только в тот момент, который ожидает автор хука, но и в еще и большом количестве неочевидных моментов. В гипотетической ситуации, когда кто-то добавляет в pre-commit хук вызов линтера, он практически гарантировано в какой-либо момент ломает кому-нибудь rebase. А если вместо линтера вызывается реформаттер, то это зачастую провоцирует гору конфликтов на каждый коммит затронутый ребэйзом. Ограничения на сообщение еще выглядят разумно, но что-то сложнее туда лучше не запихивать — слишком сложно отловить все моменты, когда это будет стрелять кому-нибудь в ногу.
Спасибо за ценный совет!
Именно линтер эффективно ставить на препуш хук. Плюсы - при локальном взаимодействии ничего не сломается. Минусы - пуш станет операцией не мгновенной.
Я у себя в проекте поставил линтер в сборке на MR. Если есть ошибка то её вижу в пайплайне реквеста и просто такие мр откладывются до исправления ошибок. Выбор подхода зависит от политики работы в команде.
В гипотетической ситуации, когда кто-то добавляет в pre-commit хук вызов линтера, он практически гарантировано в какой-либо момент ломает кому-нибудь rebase
А как линтер сломает rebase? он же не меняет код и не создает новых коммитов
В процессе ребэйза по факту множество раз происходит 3-way merge, который не обязан выдавать результат, который понравится линтеру. Особенно если где-нибудь в цепочке коммитов возникал конфликт. Гораздо правильнее при этом разрешить конфликт некрасиво, закончить ребэйз, и потом починить стиль, чем удовлетворить в какой-то момент линтер и чинить этот конфликт в каждом последующем коммите. С линтером в хуке, мы починили конфликт, продолжаем ребэйз, и в каждом коммите натыкаемся либо на линтер, либо на конфликты, либо на необходимость выключить линтер.
Увидел в статье регулярку по глаголам:
regex = r"Add: |Created: |Fix: |Update: |Rework:"
И думаю - знакомая история. А потом вспоминаю, так это же соглашение об именования коммитов!
https://www.conventionalcommits.org/en/v1.0.0/
Я тоже использую хуки гита, но в качестве инструмента проверки сообщения пользуюсь тем, что доступны по ссылке выше. Стандартизация таких вещей сильно помогает не захламлять историю коммитов в гит. А за счёт того что инструмент поддерживается комьюнити - риск словить баг работы скрипта (повешенного на хук) снижается.
Очень интересная штуковина! Я так понял, это просто соглашение, которое используется разными имплементациями - например плагином для Intelij IDEA или Python gitlint, который по сути и является commit-msg хуком, который я тут описал.
Что еще из раздела Tooling for Conventional Commits вы используете? Там так много всего
у себя на работе автоматизировал создание тегов и наполнение changelog, через скрипт в CI, который работает по этому соглашению
интересное предложение ) попробую написать
Проба пера ) https://habr.com/ru/post/585422/
Прекрасный материал! Жалко, что решение не масштабируемое: в статье рекомендуется делать все локально, но в реалиях живой команды - когда люди приходят и уходят, появляются зеленые джуны - хотелось бы, чтобы активация хуков была или автоматом, или максимально просто.
Включить добавление хуков в Onboarding page на вашу Вики, думаю, не составит труда. Даже джун справится с исполнением команды и копированием файла в папку
В мире Node.js для этого есть Husky
По мотивам этой заметки сделал проверку commit message на нашем Node.js-проекте. Трекер у нас shortcut.com, поэтому формат айдишников sc-[0-9]+, например sc-12345. Плюс в commit message оно должно быть в квадратных скобках, чтобы shortcut.com этим коммиты прицепил к тикетам. Для автоматической активации хуков используется Husky. Но не суть, всему этому есть аналоги на других стеках. Короче, вот файл .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
message="$(cat $1)"
if ! [[ $message =~ Merge|\[sc-[0-9]+\] ]];
then
storyId=$(git symbolic-ref --short -q HEAD | grep -Eo 'sc-[0-9]+')
if ! [ -n "$storyId" ]; then
echo "There's no story ID in your commit message, e.g. [sc-10000], nor could we infer it from the branch name. Please add story ID to the message. Alternatively, commit with --no-verify but that's not very cool. Read more on Shortcut+VCS here: https://help.shortcut.com/hc/en-us/articles/115003820646"
exit 1
fi
fi
и вот .husky/prepare-commit-msg
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
message="$(cat $1)"
if ! [[ $message =~ Merge|\[sc-[0-9]+\] ]];
then
storyId=$(git symbolic-ref --short -q HEAD | grep -Eo 'sc-[0-9]+')
if [ -n "$storyId" ]; then
echo "[$storyId] $message" > $1
fi
fi
Эта связка автоматически добавляет ид тикета, выведенный из названия бранча, в случае когда оной отсутствует. Если ни в commit message, ни в названии бранча ид тикета не обнаруживается, то коммитеру выводится сообщение о том, что он нехороший человек, и как обойти проверку если очень надо. Кроме того, проверка отключена для сообщений, начинающихся на "Merge".
К сожалению невозможно иметь кастомную конфигурацию для репозитория в файле .gitconfig, тк это не предусмотрено git (https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup)
[path]/etc/gitconfigfile: Contains values applied to every user on the system and all their repositories. If you pass the option--systemtogit config, it reads and writes from this file specifically. Because this is a system configuration file, you would need administrative or superuser privilege to make changes to it.~/.gitconfigor~/.config/git/configfile: Values specific personally to you, the user. You can make Git read and write to this file specifically by passing the--globaloption, and this affects all of the repositories you work with on your system.configfile in the Git directory (that is,.git/config) of whatever repository you’re currently using: Specific to that single repository. You can force Git to read from and write to this file with the--localoption, but that is in fact the default. Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.
Получается, что для каждой машины на которой вы собираетесь разворачивать репозиторий и пользоваться хуками надо сначала задать пути к хукам, а только потом делать "git clone ..."
В результате задача "ща я тут в одну команду затестирую как развернется на голой машине" уже "в один клик" не прокатит
Почему разработчики git не допускают хранения .gitconfig в папке репозитории и автоматического его подключения непонятно
Отрабатываем Git hooks на автоматизации commit message