O que é Commit e como usar Commits Semânticos

Se você já ouviu falar de commit semântico, provavelmente sabe que é padronização. Mas antes de começarmos, vamos analisar um cenário da vida real que você pode ter experimentado.

Digamos que você esteja no trabalho e encontre um novo problema no quadro de tarefas de sua equipe. Depois de um tempo analisando e lendo as necessidades, você se lembra que seus colegas de equipe fizeram algo muito parecido que poderia ajudá-lo a desenvolver sua missão. perfeito! Você examinará o código, mas não saberá que parte dele é e não se lembrará de quando foi implementado no projeto. OK, vamos ver os commits. Ao analisar, é mais fácil encontrá-los e, à medida que avança, você verá commits como “Adicionar novos recursos”, “Adicionar testes”, “Corrigir bugs”, etc.

Diante dessa situação, temos que analisar os commits um a um para encontrar o que queremos. Para coisas que são realmente projetadas para facilitar, isso pode levar muito tempo. Esta é uma situação comum em muitos outros mercados de trabalho envolvendo envios. É aí que entra nossa Submissão Semântica de Tópicos de hoje! vamos?

A padronização de Commits

Portanto, nada supera uma abordagem consistente e organizada desde a execução inicial que inclui padronização e alterações de código confirmadas durante o controle de versão.

Para tanto, é definida a especificação de Commits Semânticos para permitir que as organizações participem do processo de code commit no desenvolvimento de software.

Se você não sabe do que estamos falando, vamos voltar e explicar o que é um commit afinal:

O que é Commit

Em ciência da computação e gerenciamento de dados, um commit é um conjunto permanente de mudanças temporárias, marcando o fim de uma transação e proporcionando durabilidade para transações ACID.

O log de confirmação é chamado de log de confirmação.

O que é Commit num Sistema de Controle de Versão

Em sistemas de controle de versão como o Git, os commits adicionam as alterações mais recentes do código-fonte ao repositório, tornando essas alterações parte da revisão principal do repositório.

É importante notar que os commits em sistemas de controle de versão são mantidos no repositório indefinidamente.

Dessa forma, quando outros usuários atualizarem ou fizerem check-out no repositório, eles receberão a versão mais recente do commit.

Os sistemas de controle de versão permitem reverter facilmente para versões anteriores. Nesse caso, o commit no sistema de controle de versão é protegido porque é fácil de reverter, mesmo após a aplicação do commit.

Como fazer Commit no Git

Para “commitar” no git, basta executar o comando:

git commit -m 'mensagem do commit'

Isso também pressupõe que os arquivos no diretório atual foram testados da seguinte forma:

git add.

O comando acima adicionará todos os arquivos a serem testados no diretório de trabalho para git commit.

Depois de aplicar o commit, o passo final é enviar o commit para o repositório (chamado “geek” neste caso) para o branch master:

git push geek master

Você também pode optar por um atalho e adicionar todos os arquivos não testados e fazer um commit ao mesmo tempo com o comando:

git commit -a -m 'commit message'

Agora que você sabe o que é um commit, vamos mergulhar no commit semântico.

Como começou esta história de Commits Semânticos

Note-se que não existe uma fonte única que defina o início deste conceito. No entanto, a especificação geral de confirmação é inspirada nas diretrizes de confirmação do Angular, que definem a especificação de confirmação do Git introduzida em projetos Angular.

O primeiro rascunho desta especificação foi projetado para analisar mensagens de commit regulares no histórico do Git de forma ordenada e estruturada.

Dentre os projetos atuais que buscam alavancar o conceito e padronizar o processo, destaca-se o Conventional Commits, iniciativa que traz uma tentativa de oficializar a convenção como padrão para commits.

Em uma apresentação inicial fornecida em um site mantido pela comunidade, o envio semântico foi definido como: “Uma especificação projetada para adicionar significado legível por humanos e por máquina aos envios de mensagens”.

O que são Commits Semânticos

Commits semânticos, ou commits regulares, em sua especificação formal, são uma das maneiras pelas quais os commits podem ser padronizados em projetos de desenvolvimento de software.

Isso, usando regras simples e claras, ao mesmo tempo em que introduz uma pequena quantidade de trabalho extra, ajudará a reduzir o tempo gasto para entender como e por que algo é feito em alterações ou correções subsequentes.

Mais importante: até mesmo outro membro da equipe de desenvolvimento.

Por que usar Commits Semânticos?

É importante saber que cada abordagem precisa estar alinhada com a cultura e os processos da equipe e, para isso, sempre priorize a análise adaptativa necessária para melhor atender às necessidades da equipe de desenvolvedores.

Conceitualmente, para o processo de amadurecimento, a diretriz deve ser objetiva e assimilada rapidamente, proporcionando uma experiência de entendimento transparente para a equipe de desenvolvimento.

A utilização de padrões torna-se inerente à equipe de forma natural e consistente a partir da abstração de prefixos e tipos genéricos de processos que estão sendo executados.

Como valor principal, isso fornece uma abordagem clara e organizada para a estrutura de commits em repositórios de controle de versão.

Ganho de produtividade em equipes

No trabalho diário de um programador, ele está trabalhando sozinho em seus projetos, o que não parece um grande aumento de produtividade.

No entanto, em situações em que vários programadores estão trabalhando simultaneamente em um repositório centralizado, a adoção de um padrão na prática de todas as equipes pode melhorar muito a agilidade nas tarefas do dia-a-dia.

Uma especificação de confirmação de convenção é uma convenção simples para mensagens de confirmação. Um conjunto de regras é definido para criar um histórico de commits inequívoco, o que facilita a criação de ferramentas automatizadas.

Esta convenção descreve recursos, correções e modificações que estabelecem compatibilidade em mensagens de confirmação.

Vantagens de se usar Commits Semânticos

Em sua página oficial, o Conventional Commits lista algumas das vantagens de adotá-lo, que são:

Permite processos automatizados na geração de changelogs ou releases, resultando em documentação estruturada e consistente;

Determine automaticamente as promoções de versão semântica (com base no tipo de confirmação).

Comunique a natureza da mudança aos colegas de equipe, ao público e a outras partes interessadas.

Acionar processos de compilação e implantação.

Facilite a contribuição de outros para o seu projeto, permitindo que eles explorem um histórico de commits mais estruturado

Commits regulares encorajam tipos mais específicos de commits, como correções.

A flexibilidade dos envios regulares permite que sua equipe crie seus próprios tipos e os altere ao longo do tempo.

Commits Atômicos

Uma das principais definições do método é que as tarefas devem ser divididas em átomos: commits atômicos, que consistem em unidades de destino que implementam uma única função ou tratam de uma única correção de erro.

Ou seja, para cada patch ou implantação individual, deve ser realizado um processo de commit, que segue outro conceito de arquitetura limpa, o SOLID Single Responsibility Principle.

A estrutura dos Commits Semânticos

O commit semântico é claramente estruturado e reconhecível porque usa um formato definido em sua sintaxe, com partes obrigatórias e opcionais.

Abaixo, descreve-se a estrutura básica de uma submissão semântica, com partes obrigatórias: tipo e descrição; e partes opcionais: escopo, corpo e rodapé.

Quanto mais completo o formato de envio, maior o tempo de processamento.

Portanto, recomenda-se simplificar seu uso e não usar suas peças opcionais. Alguns casos especiais requerem uma descrição mais detalhada do processo realizado.

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

<corpo opcional>

<rodapé opcional>

Tipos

A primeira e principal descrição do commit semântico refere-se ao seu tipo, e sua finalidade é transmitir a intenção de processamento do usuário durante a execução.

Abaixo será enumerado os principais types descritos na documentação do Angular Commit Message Guidelines:

build: alterações que afetam o sistema de compilação ou dependências externas (escopo de exemplo: gulp, broccoli, npm),

ci: alterações em nossos arquivos e scripts de configuração de CI (intervalos de exemplo: Travis, Circle, BrowserStack, SauceLabs);

docs: refere-se apenas à inclusão ou alteração de arquivos de documentação;

feat: lidar com a adição de novas funcionalidades ou qualquer outra nova implementação no código;

Fix: Essencialmente define o tratamento de correções de bugs;

perf: alterações de código para melhorar o desempenho;

Refatoração: Tipos utilizados em quaisquer alterações realizadas no código, mas não alterando a funcionalidade final das tarefas afetadas;

style: Alterações no formato de renderização do código, não afetam o significado do código, como: espaços, formatos ausentes, ponto e vírgula, etc.);

Testes: adicionar testes ausentes ou corrigir testes existentes em um processo de teste automatizado (TDD);

chore: tarefas de atualização que não resultam em alterações no código de produção, mas em alterações de ferramentas, alterações de configuração e bibliotecas que não estão realmente em produção;

env: Usado principalmente para descrever alterações ou adições a arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de contêiner.

Além disso, o guia recomenda tipos de melhorias que melhoram a implementação atual sem adicionar novos recursos ou corrigir bugs.

Observe que esses tipos não são exigidos pela especificação de Commits Convencionais.

Ressalto que esses são os principais tipos a serem utilizados, mas existem vários outros que podem ser utilizados e também se adequam às necessidades do seu time de desenvolvimento.

Escopos

Os escopos podem ser adicionados aos tipos de envio, como parâmetros opcionais, para fornecer informações contextuais adicionais e colocados entre parênteses, por exemplo, feat(parser): adiciona a capacidade de analisar matrizes.

Normalmente, o uso de escopos ocorre em commits específicos e pontuais, o que requer a especificação do contexto imediato das alterações realizadas pelo commit, como em módulos de login, middleware ou arquivos de configuração.

Por exemplo, o processo de refatoração nas configurações de roteamento do módulo de login do projeto. Podemos usar escopos para descrever nossos commits semânticos da seguinte forma:

feat(login/routes): change in route settings for the login

Descrições

Descrição é um dos parâmetros obrigatórios da gramática, preferencialmente em minúsculas e deve iniciar com letra minúscula, letras maiúsculas são suportadas na descrição de um arquivo ou classe específica.

Eles também devem ser claros o suficiente para usar seu espaço na extensão máxima permitida.

test: ensure DbLoadSurveys throws if LoadSurveysRepository throws

Corpo

Os recursos físicos, por sua vez, são opcionais e seu uso raramente é recomendado.

Em suma, a descrição anterior é insuficiente para esclarecer e esclarecer onde é necessária uma imagem mais completa do que é implantado no commit.

Pode conter uma descrição mais precisa do que foi incluído no commit, apresentando o impacto e as razões para fazer alterações no código e instruções básicas para intervenções futuras.

O corpo deve começar com uma linha em branco após a descrição. Confirme se o corpo é de forma livre e pode conter qualquer número de parágrafos separados por novas linhas.

feat: ensure LoadSurveysController returns 204 if there is no content

– Returns code 204 if the search load method does not return content

Rodapé

Por fim, o rodapé também não é aplicado. Restrinja-se a mudanças de status com commits inteligentes, como solução de problemas (questões), pedindo ajuda ou implementando sprints do projeto, que podem ser descritos no rodapé.

Um ou mais rodapés podem ser fornecidos, o primeiro sempre começando com uma linha em branco após o corpo. Cada rodapé deve conter uma marca nominativa seguida do símbolo “:” (dois pontos), seguido de um espaço e o símbolo “#” (libra) como delimitador da string descritiva do rodapé (um conceito inspirado na convenção Git Trailer).

As tags de rodapé devem usar o símbolo “-” (hífen) em vez de espaço em branco, como Revisado por, para permitir que os rodapés sejam diferenciados de vários parágrafos do corpo do texto.

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Elisandro Mello

Refs #133

Pronto, agora você já sabe o que precisa sobre commits!

Vale ressaltar que você pode introduzir e adaptar gradualmente a padronização à cultura da sua equipe de desenvolvimento, ou até mesmo ao seu uso pessoal.

Se gostar, deixe seu comentário e compartilhe, pois isso ajuda esse colega a divulgar seu trabalho.