COMMITCOMO, QUANDO E POR QUE?

By @viniciusban

● Confirmar uma única unidade de trabalho

● Descrever o que foi feito

● Descrever por que foi feito

● Fazer parte de um contexto (histórico)

um commit deve

Escreva suas mensagens de

commit como se um psicopata

que sabe onde você mora fosse

lê-las.

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)

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

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

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

commit ótimo

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.

(Ao ser aceito, esse commit irá...)

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.

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.

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.

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.

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?

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?

referências

● https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_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)