Criando Commits Incríveis no Git

Marcel Gonçalves dos Santos @marcelgsantos git criando commits com incríveis

pensandonaweb.com.br tech lead e programador Marcel Gonçalves dos Santos @marcelgsantos

@phpsp phpsp.org.br

Interaja nas mídias sociais! - fale sobre o evento, palestrantes
e conteúdo - tire fotos do evento e publique - interaja com outros participantes do evento - tire dúvidas ou dê feedbacks para os palestrantes

Uma introdução diferente sobre o Git

o Git é um sistema de controle de versão decentralizado
criado pelo Linus Torvalds

porém, existe uma outra de fi nição bastante interessante que
traz uma visão diferente

"Git is fundamentally a c on tent-addressable filesystem with a
VCS us er int er face wri tt en on t op of it." - Pro Git B oo k

“o Git é, fundamentalmente, um sistema de ar quivos end
er eçável p or c on teúdo c om uma int er face de usuário de c on trol e de v er são c on s tr uída sobre ele." - Livro Pro Git

um sistema de arquivo endereçável por conteúdo é, de forma
simples, um armazém de dados do tipo chave-valor

pode-se adicionar qualquer tipo de conteúdo em um repositório Git
e ele devolverá uma chave única para poder recuperá-lo

um repositório Git possui um diretório especial onde localiza-se tudo
o que é armazenado e manipulado pelo Git

- rw - r - - r - - 1
marcel staff 64B Nov 13 17 : 28 COMMIT_EDITMSG - rw - r - - r - - @ 1 marcel staff 31K Nov 14 19 : 41 FETCH_HEAD - rw - r - - r - - 1 marcel staff 53B Nov 13 17 : 25 HEAD - rw - r - - r - - 1 marcel staff 41B Nov 13 17 : 23 ORIG_HEAD - rw - r - - r - - 1 marcel staff 440B Nov 8 01 : 37 conf i g - rw - r - - r - - 1 marcel staff 73B Jul 30 2021 description drwxr - xr - x 15 marcel staff 480B Nov 3 21 : 09 hooks - rw - r - - r - - 1 marcel staff 306K Nov 13 17 : 28 index drwxr - xr - x 4 marcel staff 128B Sep 23 18 : 20 info drwxr - xr - x 4 marcel staff 128B Sep 23 18 : 20 logs drwxr - xr - x 260 marcel staff 8.1K Nov 14 19 : 41 objects - rw - r - - r - - 1 marcel staff 58K Nov 13 17 : 37 packed - refs drwxr - xr - x 5 marcel staff 160B Sep 23 18 : 20 refs

o Git é composto por objetos e referências na sua
estrutura interna

esses elementos essenciais do Git estão localizados nos diretórios objects
e refs

- rw - r - - r - - 1
marcel staff 64B Nov 13 17 : 28 COMMIT_EDITMSG - rw - r - - r - - @ 1 marcel staff 31K Nov 14 19 : 41 FETCH_HEAD - rw - r - - r - - 1 marcel staff 53B Nov 13 17 : 25 HEAD - rw - r - - r - - 1 marcel staff 41B Nov 13 17 : 23 ORIG_HEAD - rw - r - - r - - 1 marcel staff 440B Nov 8 01 : 37 conf i g - rw - r - - r - - 1 marcel staff 73B Jul 30 2021 description drwxr - xr - x 15 marcel staff 480B Nov 3 21 : 09 hooks - rw - r - - r - - 1 marcel staff 306K Nov 13 17 : 28 index drwxr - xr - x 4 marcel staff 128B Sep 23 18 : 20 info drwxr - xr - x 4 marcel staff 128B Sep 23 18 : 20 logs drwxr - xr - x 260 marcel staff 8.1K Nov 14 19 : 41 objects - rw - r - - r - - 1 marcel staff 58K Nov 13 17 : 37 packed - refs drwxr - xr - x 5 marcel staff 160B Sep 23 18 : 20 refs

os tipos de objetos disponíveis no Git são blob, tree
e commit

o diretório objects armazena todo conteúdo de sua base de
dados, isto é, os objetos

$ f i nd .git/objects .git/objects .git/objects/a3 .git/objects/a3/968e52c871c470f1892e2feb240fb32f9cfb80 .git/objects/pack .git/objects/info
.git/objects/e6 .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 .git/objects/f9 .git/objects/f9/3e3a1a1525fb5b91020da86e44810c87a2d7bc

o diretório refs armazena ponteiros para objetos de commit

os tipos de referências disponíveis no Git são branches, tags,
remotes e outros

$ f i nd .git/refs .git/refs .git/refs/heads .git/refs/heads/main .git/refs/tags

O que é um commit?

para entender o que é um commit, precisamos entender o
que são blobs e trees

um blob é um objeto que contém apenas conteúdo e
é endereçável por um hash

ele representa o conteúdo de um arquivo propriamente dito e
nada além disso

o conteúdo de um blob é armazenado de forma compactada

$ git cat - f i le - t e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
blob

uma tree é um objeto que possui uma ou mais
entradas que apontam para blobs e trees e também é endereçável por um hash

ela representa o agrupamento de arquivos com informações relacionadas como
nomes de arquivos e modos de acesso

cada entrada de uma tree é composta por: 1. modo
de acesso, 2. tipo do objeto (blob ou tree), 3. hash do objeto e 4. nome do arquivo

$ git cat - f i le - t f93e3a1a1525fb5b91020da86e44810c87a2d7bc
tree

uma tree representa uma fotogra fi a do repositório em
determinado momento no tempo sem algumas informações

um commit é um objeto que aponta para uma tree
e possui informações relevantes como autor e mensagem de commit

um commit aponta para uma tree (fotogra fi a do
repositório) e para o commit pai (se houver)…

…e contém informações relevante como nome e e-mail do autor
ou committer e data, hora e mensagem de commit

$ git cat - f i le - t a3968e52c871c470f1892e2feb240fb32f9cfb80
commit

o commit é um elemento de alto nível o qual
lidamos no dia-a-dia

ele pode ser considerado uma fotogra fi a do repositório
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

O que é um bom commit?

1. um commit deve ser atômico, isto é, ter uma
única alteração

$ git commit - m "cria rota de cadastro e
corrige formatação"

2. um commit deve conter testes

os testes garantem que nada é quebrado ao adicionar alterações
no commit

3. um commit deve deixar o sistema sempre em um
estado estável

isto é, um commit não deve entregar algo incompleto ou
que precise de outro commit

isso facilita o rollback caso algo dê errado no momento
do deploy

$ git commit - m "cria rota de cadastro do
usuário" $ git commit - m “cria migrations da tabela”

4. um commit deve ter uma mensagem clara e descritiva

$ git commit - m "corrige rota"

5. um commit pode referenciar uma tarefa ou história em
um sistema de rastreamento de bugs

$ git commit # no editor padrão Cria rota de
cadastro do usuário Resolves: ISSUE-75

Como chegar em um bom commit?

Criar um commit atômico, com testes e em um estado
estável

um commit atômico quase sempre é resultado de uma de
fi nição adequada de tarefas ou histórias na etapa de re fi namento

é uma boa prática criar histórias e tarefas que representam
uma única alteração no software

recomenda-se criar uma branch especí fi ca para cada história
ou tarefa

$ git checkout - b feat/issue-75-cria - rota - de
- cadastro - de - produto

$ git checkout - b f i x/issue-99-corrige - formatacao
- do - preco

em uma branch especí fi ca você terá total liberdade
para trabalhar como quiser

você pode, tranquilamente, ter commits com trabalhos incompletos já que
não se trata da versão fi nal de seu trabalho

no fi nal, deve-se consolidar todos os commits em apenas
um commit que representa a entrega da funcionalidade

antes de criar uma pull request recomenda- se fazer um
"self code review"

rode ferramentas de qualidade de código como testes automatizados, estilo
de código, linters, type checking entre outras análises

se precisar corrigir algo de última hora, utilize o comando
git commit --amend

e, o mais importante, escreva uma mensagem de commit que
seja clara e descritiva!

Escrever uma mensagem de commit clara e descritiva

o Git é uma ferramenta de documentação e o seu
histórico permite ver a evolução do software ao longo do tempo

e um bom histórico depende de mensagens de commits bem
escritas

o sucesso de um projeto de longo prazo é graças
a sua manutenibilidade e o histórico de commits é essencial para isso

a maioria das linguagens de programação possuem convenções bem estabelecidas
para nomes, formatação e outros

e para mensagens de commit não é diferente!

As sete regras de uma boa mensagem de commit

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á com di fi culdade para resumir o que
foi feito, o commit pode ter muita responsabilidade

o limite de 50 caracteres não está escrito em pedra

é difícil de alcançar em idiomas como português ou quando
adiciona-se contexto no título

procure tentar 50 caracteres e, se não for possível, considere
72 caracteres como limite máximo

3. começar o título com letra maiúscula

4. não fi nalizar o título com ponto fi nal

5. usar modo imperativo no título

fale ou escreva como se tivesse dando um comando ou
instrução

como nos exemplos abaixo: - limpa o quarto - fecha
a porta - corrige o texto

o modo imperativo pode parecer rude mas o próprio Git
o utiliza em suas mensagens

6. limitar a largura do corpo em 72 caracteres

o Git não realiza a quebra de linhas de forma
automática

se você escreve o corpo da mensagem é sua responsabilidade
realizar a quebra manualmente

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

ela 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 especi fi cação

a convenção está de acordo com o semantic versioning ao
descrever features, fixes e breaking changes na mensagem de commit

a mensagem do commit deve ter a estrutura a seguir…

<tipo>[escopo opcional] : <descrição> [corpo opcional] [cabeçalho(s) opcional(is)]

os tipos de commits mais comuns são fi x e
feat

o tipo fi x indica a correção de um bug
na sua base de código e é equivalente ao patch no semantic versioning

o tipo feat indica a introdução de uma nova funcionalidade
na sua base de código e é equivalente ao minor no semantic versioning

feat: adiciona envio de email ao concluir a compra

f i x: corrige texto do botão de cadastro

um commit pode ser do tipo breaking change e, para
isso, deve-se adicionar um rodapé com breaking change: ou adicionar ! depois do tipo ou escopo do commit

feat(api)!: adiciona campo de cpf obrigatório no cadastro

existem outros tipos além de fi x e feat que
são permitidos como build, chore, docs e refactor

docs: corrige ortograf i a em CHANGELOG

style: ajusta estilo de código em CreateUser

os benefícios de adotar conventional commits são muitos como…

1. automatizar a geração de changelogs

2. fazer o bump de versão de forma automática

3. comunicar a natureza das alterações para colegas de equipe,
público ou stakeholders

4. disparar processos de build e publicação

5. facilitar a compreensão do históricos de commits do seu
projeto

a especi fi cação Conventional Commit é inspirada e baseada
fortemente no Angular Commit Guidelines

Como garantir que um commit continue bom?

recomenda-se criar guidelines para a criação de commits na sua
equipe

não é necessário seguir fi elmente as sete regras ou
conventional commits mas elas são consolidadas na comunidade

utilize o que melhor se adaptar a sua equipe

pode-se utilizar ferramentas de lint como o commitlint que veri
fi ca se a mensagem está de acordo com padrão

ou ferramentas que auxiliam na criação de um commit como
o commitzen

Conclusão

o Git vai além de uma ferramenta de controle de
versão

o Git é também uma ferramenta de documentação e o
seu histórico permite ver a evolução do software ao longo do tempo

e um bom histórico depende de commits atômicos, com testes
e em um estado estável e de mensagens de commits bem escritas

o sucesso de um projeto de longo prazo é graças
a sua manutenibilidade e o histórico de commits é uma ferramenta essencial

vá em frente, crie commits incríveis e divirta-se!

Referências

bit.ly/palestra-commits-incriveis

Avalie!

@marcelgsantos speakerdeck.com/marcelgsantos Obrigado. Perguntas?

Criando Commits Incríveis no Git

Criando Commits Incríveis no Git

More Decks by Marcel dos Santos

Other Decks in Programming

Featured

Transcript