Executando verificação de segurança...
21
kaykemigon
6 min de leitura ·

[Git] Como escrever boas mensagens de commit do Git

Padrões de commits 📜

De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas.

Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.

Essa identificação ocorre por meio de uma palavra e emoji que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração de visual, teste...

Tipo e descrição 🦄

O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

  • feat- Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

  • fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

  • docs - Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

  • test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

  • build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

  • perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

  • style - Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código).

  • refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

  • chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

  • ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

  • raw - Commits to tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parametros.

Recomendações 🎉

  • Adicione um tipo consistente com o título do conteúdo.
  • Recomendamos que na primeira linha deve ter no máximo 4 palavras.
  • Para descrever com detalhes, usar a descrição do commit.
  • Usar um emoji no início da mensagem de commit representando sobre o commit.
  • Os links precisam ser adicionados em sua forma mais autêntica, ou seja: sem encurtadores de link e links afiliados.

Complementos de commits 💻

  • Rodapé: informação sobre o revisor e número do card no Trello ou Jira. Exemplo: Reviewed-by: Elisandro Mello Refs #133
  • Corpo: descrições mais precisas do que está contido no commit, apresentando impactos e os motivos pelos quais foram empregadas as alterações no código, como também instruções essenciais para intervenções futuras. Exemplo: see the issue for details on typos fixed.
  • Descrições: uma descrição sucinta da mudança. Exemplo: correct minor typos in code

Padrões de emojis 💈

Tipo do commit Emoji Palavra-chave
Acessibilidade ♿ :wheelchair:
Adicionando um teste ✅ :white_check_mark: test
Adicionando uma dependência ➕ :heavy_plus_sign: build
Alterações de revisão de código 👌 :ok_hand: style
Animações e transições 💫 :dizzy:
Bugfix 🐛 :bug: fix
Comentários 💡 :bulb: docs
Commit inicial 🎉 :tada: init
Configuração 🔧 :wrench: chore
Deploy 🚀 :rocket:
Documentação 📚 :books: docs
Em progresso 🚧 :construction:
Estilização de interface 💄 :lipstick: feat
Infraestrutura 🧱 :bricks: ci
Lista de ideias (tasks) 🔜 :soon:
Mover/Renomear 🚚 :truck: chore
Novo recurso ✨ :sparkles: feat
Package.json em JS 📦 :package: build
Performance ⚡ :zap: perf
Refatoração ♻️ :recycle: refactor
Removendo um arquivo 🔥 :fire:
Removendo uma dependência ➖ :heavy_minus_sign: build
Responsividade 📱 :iphone:
Revertendo mudanças 💥 :boom: fix
Segurança 🔒️ :lock:
SEO 🔍️ :mag:
Tag de versão 🔖 :bookmark:
Teste de aprovação ✔️ :heavy_check_mark: test
Testes 🧪 :test_tube: test
Texto 📝 :pencil:
Tipagem 🏷️ :label:
Tratamento de erros 🥅 :goal_net:
Dados 🗃️ :card_file_box: raw

💻 Exemplos

Comando Git Resultado no GitHub
git commit -m ":tada: Commit inicial" 🎉 Commit inicial
git commit -m ":books: docs: Atualização do README" 📚 docs: Atualização do README
git commit -m ":bug: fix: Loop infinito na linha 50" 🐛 fix: Loop infinito na linha 50
git commit -m ":sparkles: feat: Página de login" ✨ feat: Página de login
git commit -m ":bricks: ci: Modificação no Dockerfile" 🧱 ci: Modificação no Dockerfile
git commit -m ":recycle: refactor: Passando para arrow functions" ♻️ refactor: Passando para arrow functions
git commit -m ":zap: perf: Melhoria no tempo de resposta" ⚡ perf: Melhoria no tempo de resposta
git commit -m ":boom: fix: Revertendo mudanças ineficientes" 💥 fix: Revertendo mudanças ineficientes
git commit -m ":lipstick: feat: Estilização CSS do formulário" 💄 feat: Estilização CSS do formulário
git commit -m ":test_tube: test: Criando novo teste" 🧪 test: Criando novo teste
git commit -m ":bulb: docs: Comentários sobre a função LoremIpsum( )" 💡 docs: Comentários sobre a função LoremIpsum( )
git commit -m ":bulb: raw: RAW Data do ano aaaa" 🗃️ raw: RAW Data do ano aaaa

Fonte: https://github.com/iuricode/padroes-de-commits

Carregando publicação patrocinada...
4
0
3
kht

Complementando, seguem outros posts sobre o assunto:

Dito isso, não gosto dessa ideia de colocar emojis, acho que gera ruído e mais atrapalha do que ajuda (e sem querer parecer grosseiro, mas sinceramente acho uma grande bobagem). Sem contar que muitos são redundantes, pois a palavra-chave já seria mais que suficiente.

De qualquer forma, acho importante a ideia de ter mensagens descritivas, detalhadas e padronizadas, na medida do possível. Só não encare essa - e qualquer outra metodologia - como uma lei imutável escrita na pedra. Eu vejo mais como recomendações, que podem ser adaptadas para cada contexto.

0
maike

Discordo. Nós, humanos, somos seres visuais e interpretamos imagens e objetos de forma mais eficiente do que letras e números. Por exemplo, ao revisar um commit, ao ver o emoji 🐛, identificamos imediatamente que se trata de um bug e podemos determinar se é urgente ou não. Por isso, as placas de trânsito contêm símbolos e desenhos, devido à nossa natureza visual.

2
kht

O problema dos emojis é que eles não são tão "universais" como muitos imaginam. Tem muito mais problemas de compatibilidade do que um texto "normal".

Por exemplo: um mesmo emoji, em cada combinação de sistema operacional + aplicação (browser, editor, etc), pode ser exibido com uma imagem completamente diferente. É o oposto do que acontece com sinalização de trânsito, muito mais padronizado do que emojis (mas ainda sim, não elimina a necessidade de texto, já que muitas precisam ter os nomes de bairros ou cidades, etc).

Sem contar que muitos ainda preferem a linha de comando em um terminal, que nem sempre é compatível com emojis (e mesmo quando é, tem ainda a questão de exibir imagens diferentes em cada terminal). Fora as diferenças culturais, que fazem com que um mesmo emoji possa ter interpretações completamente diferentes. No fim das contas, um texto bem escrito elimina todos esses problemas.

Outro ponto é que essa história de que todo mundo é "visual" não é unânime. Há pesquisas que mostram que existem pessoas que não são, e usam outros sentidos no lugar (audição, por exemplo).

E mesmo que todo mundo fosse visual, o estímulo não se dá exclusivamente por imagens. Texto estruturado também forma padrões reconhecíveis, uma simples marcação como [BUG] pode dar o mesmo efeito (e sem a poluição visual que os emojis - na minha opinião - desnecessariamente causam).

E tem ainda os deficientes visuais, que embora sejam minoria na nossa área, existem e não podem ser ignorados. Eles geralmente usam screen readers, e para estes, emojis podem atrapalhar bastante.

Mas claro, se toda a equipe concordar (ou obrigar), então que usem emojis. Eu ainda acho que tem hora e lugar pra usar, e em mensagem de commit não acho adequado.

0
maike

De fato, os emojis não são universais, da mesma forma que as placas de trânsito não são padronizadas no mundo todo. Alguns emojis podem ter significados distintos em diferentes países, assim como as placas podem variar.

Além disso, o uso de emojis abordado na publicação claramente apresenta texto e um contexto junto do emoji. Dessa forma, não estamos substituindo o uso de palavras por emojis, mas sim contextualizando uma mensagem com uma figura e, em seguida, elaborando melhor o restante do commit explicando o propósito em texto claro. Assim, o emoji serve apenas como contextualizador geral da informação.

Quanto à questão dos emojis não serem suportados em todos os terminais e ter suas variações, acredito que o texto que acompanha o commit em sua essência resolve esse tipo de problema de compatibilidade.

É importante ressaltar que somos seres visuais, e mesmo que alguns indivíduos se comuniquem melhor oralmente, a percepção visual é um sentido fundamental. Além disso, os emojis têm seu papel na história humana como um todo.

Por fim, acredito que os emojis têm o poder de auxiliar no versionamento de código, desde que se mantenha um padrão estabelecido pela equipe e todos estejam de acordo com as diretrizes apresentadas. Afinal, no fim das contas, são os desenvolvedores atuantes do projeto que precisam compreender o padrão de commit.

2
kht

acredito que o texto que acompanha o commit em sua essência resolve esse tipo de problema de compatibilidade

Exatamente. E se o texto já resolve a questão, o emoji acaba sendo desnecessário.

Se o emoji confunde e precisa do texto para ser esclarecido, então ele deveria ser removido. E se ele tem o mesmo sentido do texto, é redundante. Em ambos os casos, portanto, acho desnecessário.

Quanto à percepção visual, embora seja fundamental para a maioria, acaba por excluir deficientes visuais. Como já dito, embora sejam minoria na área, não é algo desprezível e emojis dificultam a leitura por screen readers, conforme link já enviado acima.

0
2
caiquearaujo

Como eu tinha MUITA preguiça de escrever tudo isso, há muito tempo atrás fiz um comando em python para otimizar meu processo interno. Não é uma lib finalizada, mas o commit ela faz que é uma beleza: https://github.com/caiquearaujo/gitpy.

Eu utilizo muito uma variação do GitFlow nos meus projetos, então existem outros comandos por lá (não finalizados, recomendo apenas para experimentação). Para mim é produtivo ser um comando guiado, mas quem quiser fazer um fork e personalizar...

1
1
1
1
0