Gostei demais, eu estava mesmo querendo um documento tão simples explicando isso. Sobre os commits só o que me incomoda é ter que ser breve, as vezes eu sinto que a mensagem do commit não explica tudo o que eu fiz, não sei se faço coisas de mais em um unico commit. Qual é o certo a se proceder, fazer mais commits com descrições breves ou menos commits que alterem bem mais código e com descrições longas?
Em resposta a Guia de bolso para Commits Semânticos
1
1
Cara isso depende muito do projeto. Se você fizer muitas alterações que vão impactar o sistema, eu acho que descrever tudo o que foi feito é legal, mas tem que descrever bem resumidamente para que não fique muito extenso. Uma dica que um senior me passou uma vez é "descrever com muitos detalhes, porém em poucas palavras", mas isso é um processo de aprendizado com o tempo você pega jeito do que colocar e tal, esses commits semânticos já são um bom passo pra resumir tuas tarefas.
1
Se a descrição do commit não cabe no titulo dentro do limite do conventional commits, significa que você está fazendo muita alteração em um só commit. :-)
Uma boa prática é referenciar ao issue que descreve a tarefa que você está executando.
feat(login): allow social login
implements a social login method using package laravel/socialite package.
refs: #2384
Desta forma tem uma descrição clara porém resumida do commit. Outros detalhes podem estar na conversação da issue #2384.
Mesmo em projetos solo, eu abro issues para todas as tarefas, e todos os commits são referenciados, assim dentro da issue eu também vou ter uma referência a quais commits desenvolveram aquela tarefa.
Na issue eu escrevo meus pensamentos, motivações para aquela feature, passos para reproduzir um determinado bug, e inclusive passos que usei até chegar a causa do problema. acredite, no futuro você vai ter um bug parecido, e vai lembrar que escreveu lá a solução. as vezes isso vai te poupar horas ou até dias.