Комментарии 12
поэтому лучше использовать инструменты, способные автоматически вносить исправления.
Меня в таких схемах всегда смущает, что история коммитов и, как следствие, блейминг кода превращается в какую-то кашу иногда. Поэтому интересно мнение публики: это точно хороший совет - переносить исправление кода на уровень ci, а не на уровень правил автоформатирования в ide?
Обычно после того как ты в PR видишь коммит от линтера, ты сам делаешь squash и идешь настраивать IDE чтобы она перед сохранением форматировала.
В одном из проектов, над которым я работал, автоматическое форматирование было сделано на уровне pre-commit-hook. Причем использовалась наивная реализация, когда из хука запускается программа форматирования, которая форматирует код всего проекта, но никак не обновляет данные для коммита. Это приводило к тому, что после коммита в рабочей копии появлялись изменения с правильным форматированием файлов, но они не попадали коммит.
Я бы использовал автоформатирование на двух уровнях: изменяющее, на уровне IDE, и проверяющее, на уровне CI. Конечно, это должна быть одна и та же программа с одинаковым набором правил.
Это не проблема, гит сейчас умеет игнорировать определенные изменения при блейме. Нужно всего лишь добавить хешы нужных коммитов в файл .git-blame-ignore-revs . Подробнее тут.
это проблема, потому что этим придется заниматься: сидеть и коммиты переписывать из лога в файл.
дичь какая)
Нет, этим не нужно заниматься, этим занимаются автоматизированные инструменты. Коммитят свои исправления и затем коммитят хеш коммита в этот файл.
история потом выглядит примерно так?
то есть после каждого коммита есть мусорный коммит с "подтиранием" линтером?
- chore: auto linter
- feature: x implemented close: #12345
- chore: auto linter
- feature: y implemented close: #12344Для новых фич это не надо, т.к. для них массовые изменения автотулзами не нужны.
В нашем случае это используется для массового рефакторинга сделанных автотулзами. Или для изменений сделанных ботами в полностью автоматическом режиме, например обновился корпоративный стандарт кода, бот обновляет зависимость с правилами для phpcs, запускает переформат кода, коммитит изменения и создает pr. Человек должен только его заапрувить. Что там два коммита вместо одного честно говоря совершенно всё равно.
Хотелось бы добавить ещё один очень простой инструмент проверки на синтаксические ошибки, перед слиянием, средствами самого php (очень помогает ловить мелкие очепятки в коде, без запуска "тяжёлых" анализаторов)
`find ./src -type f -name '*.php' -print0 | xargs -0 -L1 -P4 -- php -l -f`
Ищем все *.php файлы в папке src и пихаем их в интерпретаро, в режиме проверки синтаксиса.
Маст-хэв PHP-инструменты