Стандартные коммиты не спасут ваши сообщения коммитов
Исследуем, почему простого следования стандартам коммитов недостаточно для написания хороших сообщений коммитов, и представляем ключевые стратегии мышления для улучшения вашего процесса разработки и естественного создания значимых коммитов.
Быстрый поиск в интернете покажет множество статей о том, как писать сообщения коммитов. 90% из этих статей говорят вам использовать стандартные коммиты. Однако значительное число разработчиков все еще испытывают трудности с этим. Они знают, что должны следовать этим стандартам, но им трудно применять их на практике. Каждый раз, когда они коммитят код, они мучаются, писать ли "рефакторинг" или "задание". Я даже видел проекты, где список сообщений коммитов состоит исключительно из одного и того же сообщения: "фича: добавить страницу", потому что написание сообщений коммитов было для них слишком сложным, и они просто сдались.
Еще рано говорить о стандартных коммитах
Я не говорю, что стандартные коммиты плохие. У них много известных преимуществ:
- Они обеспечивают единый формат, делая сообщения коммитов более стандартизированными
- Они удобны для парсинга автоматическими инструментами, обеспечивая автоматическое создание журналов изменений
- Они помогают членам команды понять цель и объем изменений в коде
- Они позволяют быстро идентифицировать различные типы изменений в коде
Однако, когда разработчик все еще испытывает трудности с написанием хороших сообщений коммитов даже после использования стандартных коммитов, давать ему статью о том, как использовать стандартные коммиты, учить его, что значит тип фича
, что значит тип починка
, на самом деле бессмысленно. Это как дать продвинутую кулинарную книгу тому, кто не умеет готовить, не научив его пользоваться основными ингредиентами и инструментами. Тем не менее, такие статьи повсюду в интернете. Мало кто понимает, что стандартные коммиты могут быть действительно эффективными, только когда у разработчиков есть четкое мышление и способность точно делить задачи.
Поэтому стандартные коммиты не плохи, но прежде чем дойти до них, нам нужно установить правильный подход к разработке и использовать научное мышление разработчика.