Thread by @marcelgsantos

Galera, a dica de hoje é sobre GIT. Uma ferramenta MUITO IMPORTANTE e utilizada no dia-a-dia de quem trabalha com programação e que ainda causa MUITA DÚVIDA, desde iniciantes até pessoas mais experientes. Nesta thread eu vou falar como fazer um BOM COMMIT. Bora lá? #devtips #git

Vou começar com a DEFINIÇÃO de um commit. Um COMMIT é, de maneira simples, uma FOTOGRAFIA DO REPOSITÓRIO de código com INFORMAÇÕES RELEVANTES em um determinado MOMENTO NO TEMPO.

Um CONJUNTO DE COMMITS em ordem cronológica é responsável por CONTAR A HISTÓRIA do seu repositório.

As INFORMAÇÕES RELEVANTES contidas em um commit são:

1. referência para o COMMIT PAI (se houver)
2. nome e e-mail do(a) AUTOR(A) e/ou COMMITTER
3. DATA E HORA do commit
4. MENSAGEM do commit

O que é um BOM COMMIT?

1. um bom commit deve ser ATÔMICO, isto é, ter uma ÚNICA ALTERAÇÃO

ex:
- cria rota de cadastro do usuário
- corrige exibição do botão editar

2. um bom commit deve conter TESTES

Os testes garantem que NADA É QUEBRADO ao adicionar alterações no commit.

3. um bom commit deve deixar o sistema sempre em um ESTADO ESTÁVEL

Não deve entregar funcionalidade PELA METADE ou que precisa de outro commit. Isso FACILITA O ROLLBACK caso algo dê errado no momento do deploy.

ex:
- cria rota de cadastro do usuário
- cria migrations da tabela

4. um bom commit deve ter uma MENSAGEM CLARA e DESCRITIVA

Vou falar sobre esse ponto com MAIS DETALHES a seguir!

5. um bom commit pode REFERENCIAR uma tarefa ou história em uma ferramenta de gerenciamento de tarefas.

ex:
Cria rota de cadastro do usuário

Resolves: ISSUE-75

Como escrever uma MENSAGEM CLARA e DESCRITIVA?

O Git é uma ferramenta de DOCUMENTAÇÃO e COMUNICAÇÃO. O seu histórico permite ver a evolução do software e as decisões tomadas ao longo do tempo.

AS SETE REGRAS

1. separar o título do corpo com uma LINHA EM BRANCO

- nem toda mensagem de commit precisa de corpo
- normalmente utilizada em situações de alterações simples que não precisam de contexto

2. limitar o título em 50 CARACTERES

- torna o TÍTULO LEGÍVEL e força o autor a pensar de forma MAIS CONCISA
- se está difícil para resumir, o commit pode ter MUITA RESPONSABILIDADE
- o limite não está ESCRITO EM PEDRA
- DIFÍCIL DE ALCANÇAR em idiomas como o português ou...

...quando existe contexto no título

3. começar o título com LETRA MAIÚSCULA

4. não finalizar o título com PONTO FINAL

5. usar MODO IMPERATIVO no título

- escreva como se tivesse dando um comando ou instrução
- o modo parece rude mas o próprio Git o utiliza em suas mensagens

6. limitar a largura do corpo em 72 CARACTERES

- o Git não faz a quebra de linhas de forma automática
- o seu editor ou IDE pode te auxiliar na quebra

7. usar o CORPO DA MENSAGEM para explicar O QUE, COMO e POR QUE

CONVENTIONAL COMMITS

O Conventional Commits trata-se de uma CONVENÇÃO SIMPLES para mensagens de commit. Ele fornece um CONJUNTO DE REGRAS fácil para criar um histórico de commit explícito o que facilita a criação de ferramentas automatizadas com base na especificação.

A convenção está de acordo com o SEMANTIC VERSIONING ao descrever features, fixes e breaking changes direto na mensagem de commit. A MENSAGEM DE COMMIT deve ter a seguinte estrutura:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[cabeçalho(s) opcional(is)]

Os TIPOS DE COMMITS mais comuns são fix e feat.

O tipo `fix` indica a CORREÇÃO DE UM BUG no seu código e é equivalente ao PATCH no semantic versioning.

O tipo `feat` indica a introdução de uma NOVA FUNCIONALIDADE no seu código e é equivalente ao MINOR no semantic versioning.

Um commit pode ser do tipo BREAKING CHANGE e, para isso, deve-se adicionar um rodapé com BREAKING CHANGE: ou adicionar ! depois do tipo e/ou escopo do commit.

Existem OUTROS TIPOS além de fix e feature que são permitidos como build, chore, docs e refactor.

Usar o Conventional Commits traz DIVERSOS BENEFÍCIOS como:

- fazer o bump de versão de forma automática
- comunicar a natureza das alterações para colegas de equipe, público ou stakeholders
- disparar processos de build e publicação
- automatiza geração de changelogs

A mensagem abaixo é um EXEMPLO de um BOM COMMIT que utiliza grande parte das recomendações acima e que fazem sentido no meu contexto.

Como garantir as BOAS PRÁTICAS?

Recomenda-se CRIAR GUIDELINES para a criação de commits na sua equipe. Não é necessário SEGUIR FIELMENTE as Sete Regras ou o Conventional Commits mas elas são um bom PONTO DE PARTIDA já que são regras consolidadas na comunidade.

O ponto é: utilize o que MELHOR SE ADAPTAR a sua equipe.

Pode-se utilizar também FERRAMENTAS como o `commmitlint` que verifica se a mensagem ESTÁ DE ACORDO COM O PADRÃO e o `commitzen` que AUXILIA A CRIAÇÃO de commits seguindo as regras estabelecidas.

Configure seu EDITOR PREFERIDO no git e use o comando `git commit` em vez de `git commit -m` para ter a ajuda do syntax highlight do editor na MENSAGEM DE COMMIT.

Espero que essas dicas tenham sido úteis para você! :)