Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Да ладно, в текущем году, упомянуть python, но не поставить ruff-pre-commit или не указать альтернативы mypy, эт жирный минус.
Кажется, автор изобрел велосипед.
https://pre-commit.com/
Все ещё считаю, что коммитить плохой код - это нормально. Промежуточные результаты работы - тоже результаты и терять их не хочется (например, если это результаты вашего коллеги, который внезапно заболел). Мерджить такой код конечно не надо, но в отдельной ветке пусть лежит, жалко что ли
Согласен! Вы же всегда можете временно отключить pre-commit скрипты и пролить ветку в репозитори, а внутри репозитория вас уже не пропустит CI.
Но я всё же против такого подхода, так как считаю, что commit - это точка наиболее стабильной версии кода. По этой причине я при каждом коммите запускаю проверку тестов.
Я в пет проекте сейчас 2 недели пилю новую сложную фичу. До стабильной версии ещё много, постоянно что-то не так. Мне не коммитить?
Нет, коммит - это не стабильная версия. Это окончание какой-то мысли, какого-то этапа работы. Стабильная версия будет после мерджа
Ну да, перефразировали и выдали за правильное определение!
Вы на, так называемое "окончание мысли", не пишите автотесты? Не подгоняете code style под общий стандарт? Не следите за ошибками?
Если вы всё это делаете, то вам не стоит бояться pre-commit проверок. Я в статье написал, что мои pre-commit скрипты проверяют только измененные файлы. А внутри pre-push проверяется уже весь проект целиком, чтобы лишний раз не гонять CI.
`git commit --no-verify` ?
Да даже если код хороший... Тонна пре-коммит хуков сделает из 2х секундной операции - 2х минутную. Даже если код пройдёт все эти проверки, это же ужас в ежедневной работе.
Тоже считаю что всё это запускать надо перед мерджем ПР. Иначе любой коммит, ребейз, сквош превратится в пытку.
Я не хотел делать акцент на событие pre-commit! В моём репозитории собраны скрипты и для pre-push.
Идея была в том, чтобы проводить проверки локально, чтобы избежать таких мелочей, как "лишний импорт", неправильные отступы и отсутствие типизации.
Вы самостоятельно можете комбинировать нужные вам скрипты!
Ненавижу git-хуки, которые не дают мне коммииить любой код, какой хочу.
Одно дело которые корректируют и улучшают без твоего импакта, а другое дело когда вообще коммитеть не дают. Ты задолбешься этот рубильник выключать и включать. Столько ситуаций когда нужно как есть коммитеть что не перечесть.
Поэтому отношу это всё скорее к вредным советам, которые полезны меньшинству чем большинству.
Пусть улучшает отдельным коммитом. А то так улучшит, что не откатить потом
ну при мне нормальные матерые стилизаторы тот же astyle для плюсов, Prettier для js и т.п. для каждого из языков никогда ничего не ломали - вполне доверяю и на коммиты ставить. Если что-то более сложное человеку хочется настроить на коммит - то да, можно отдельным обезопасить себя.
Плюсы и js не закладывают в отступы семантику. Код не меняет из-за отступов, можно форматировать как угодн. В питоне сиутация не такая - изменение форматирования может сломать код, поэтому форматирование закладывается на этапе написания - как вижу так он работать и будет. И вот если вдруг ты решил закоммитить сырой сломанный код (мало ли что случилось, очень надо), некоторые форматтеры могут решить что отформатировать его всё равно надо и что-то куда-то передвинуть
Посмотрите в сторону biome как альтернатива prettier и lint. Быстрее раз в 10. И да слышали ли вы про подход trophy для fe ?
Отлично! С biome не работал, но обязательно посмотрю!
"...слышали ли вы про подход trophy для fe ?" - не совсем понял, что вы имеете ввиду. Опишите пожалуйста подробнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git-хуки, которые не дают коммитить плохой код