O documento fornece diretrizes para escrever mensagens de commit no Git de forma clara e informativa. Recomenda-se que cada commit confirme uma única unidade de trabalho e descreva o que foi feito e por quê de forma que outro desenvolvedor entenda sem precisar de contexto adicional. Deve-se commitar com frequência, preferencialmente dezenas de vezes por dia, para contar a história do desenvolvimento de forma clara.

1. COMMIT
COMO, QUANDO E POR QUE?
By @viniciusban

2. um commit deve
● Confirmar uma única unidade de trabalho
● Descrever o que foi feito
● Descrever por que foi feito
● Fazer parte de um contexto (histórico)

4. Escreva suas mensagens de
commit como se um psicopata
que sabe onde você mora fosse
lê-las.

5. recomendações
● Commit com frequência
● Descreva apenas uma unidade de trabalho
● Dezenas ao dia
● Conte uma história
● Insira referências (tickets, outros commits e
materiais de recomendação)

6. commits bons e ruins (1)
Conserta o header
(ao ser aceito, esse commit irá)
Mudar o ID css do titulo do header que ficava
escondido por baixo da imagem

7. commits bons e ruins (2)
Conserta o header (2)
(ao ser aceito, esse commit irá)
Incluir o novo arquivo header.css que eu
esqueci no commit anterior
Dica: use git commit --amend para essa situação

8. commits bons e ruins (3)
Ajusta header com js
(ao ser aceito, esse commit irá)
Ajustar o header com js ao inves de apenas
CSS...
- Closes #284

9. commit ótimo
(Ao ser aceito, esse commit irá...)
Corrigir bug q impede usuario de se inscrever...
Os usuarios sao impedidos de se registrar se nao
visitaram antes a pagina de planos e precos.
Contavamos que a informacao de trilha existiria para os
logs que criamos depois que um usuario se registrava.
Corrigi, fazendo o logger so gravar se essa informacao
estiver disponivel.
- Closes #2873942 http://sistema-de-demandas/ticket
- O commit d2438a2 tentou corrigir, mas falhou.

10. dicas (parte 1)
● 1ª linha do commit
– É o assunto, como num email, com 50
caracteres.
– Abrevie com bom senso.
– Termine com “...” se houver corpo da
mensagem
– Deixe uma linha em branco depois dela.

11. dicas (parte 2)
● Adote um padrão para commits padrão
– “pep8”, “identar”, “organizar fonte”
– “Criar crud clientes” (só se for gerado
automaticamente)
● Não ache um padrão aonde não existe:
– Refatoração
– Renomear variáveis, métodos, funções.

12. problemas
● PROBLEMAS
– Não consigo resumir o que eu fiz em apenas 50
caracteres
– O resumo do commit tem a conjunção "e"
● SUGESTÃO
– Diminua a unidade de trabalho.
– git add -p ajuda a identificar as unidades lógicas
e a quebrar o commit.
– Não misture mexida de identação, por exemplo,
com alterações funcionais no mesmo commit.

13. problemas
● PROBLEMAS
– Quando lembro de commitar, já mexi em um
monte de coisa
● SUGESTÃO
– Defina objetivos antes de começar a codificar.
– Faça uma lista de TO-DO no próprio programa.

14. problemas
● PROBLEMAS
– Commitar toda hora é chato e cansativo
● SUGESTÃO
– Pense que cada commit ajuda a contar a história
do que você está fazendo no sistema.
– Imagine você dando um git log daqui a 6 meses.
O histórico que você está criando te ajudará a
descobrir um bug ou a entender uma opção de
projeto?

15. problemas
● PROBLEMAS
– Eu não acho necessário descrever tudo o que fiz
● SUGESTÃO
– Imagine que a mensagem de commit é um email
que você só vai ler daqui a 6 meses. Você
entenderia o que foi feito lendo essa mensagem?

16. referências
● https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_comm
it_message_structure
● http://chris.beams.io/posts/git-commit/
● http://www.slideshare.net/TarinGamberini/commit-messages-goodpractices
● http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-
elegant-git-history/
● https://github.com/blog/926-shiny-new-commit-styles
● http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
● https://gitlab.com/help/markdown/markdown.md#special-gitlab-references
(só acessa logado)