Comments 10
поэтому лучше использовать инструменты, способные автоматически вносить исправления.
Меня в таких схемах всегда смущает, что история коммитов и, как следствие, блейминг кода превращается в какую-то кашу иногда. Поэтому интересно мнение публики: это точно хороший совет - переносить исправление кода на уровень 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-инструменты