Hoje nas empresas é muito comum o uso das estruturas recomendadas pela Convenção de Commits
A especificação Conventional Commits é uma convenção sobre as mensagens de confirmação. Ele fornece um conjunto fácil de regras para criar um histórico de confirmação explícito; o que facilita a escrita de ferramentas automatizadas.
No começo parece ser confuso, o que usar, quando usar e onde usar? rsrs Mas você acaba se habituando e se acostumando com o padrão.
Gostaria de ressaltar o segundo ponto da questão:
"mas este projeto só eu desenvolvo ele, não tem o porque ficar pensando em mensagem de commit."
Fora ser uma boa prática, lembre sempre que "Quem fornece ajuda, recebe ajuda!". Você especificar bem um commit, ajuda outros desenvolvedores futuros a entenderem o caminho que foi tomado e o que foi modificado... Claro que ajuda na prevenção e resolução de bugs (já que você está versionando o seu código), mas creio que o principal do commit é ajudar na comunicação do time de devs, já que temos que cumprir uma série de etapas("commit, abre pullrequest, solicita(e faz) o code review, mergeia a PR na development, teste em hml, mergeia a development na main... Enfim...)para podermos entregar o "produto" final...
Creio que é uma boa seguir essa estrutura que o Conventional Commits nos oferece... O kunzgabriel respondeu esse post, dando a dica de usar o Husky e o Commitizen, o que eu também recomendo! Abaixo vou deixar o link das documentações e cheat sheet:
Maravilha! Estou tentando me acostumar a usar versionamento/git, mas é um processo sempre complicado. E o commit é aquela etapa que ainda preciso entender bem.
Às vezes passo um dia trabalhando e mexo em vários arquivos de algum projeto pessoal e 'commito' tudo de uma vez, fica uma bagunça. Penso que pelo discutido aqui, preciso me organizar para dar commit a cada etapa (ou realizar o commit de cada arquivo separadamente).