/padroes-e-nomenclaturas-no-git

Esse projeto consta com link's de pesquisas para padrões, nomenclaturas e fluxo de trabalho com Git.

Banner do Readme

Padrões e Nomenclaturas no Git

Padrões Branches • Padrões Commits • Fluxo de Trabalho com GIT • Ferramentas • Referências • Autor

Branches

Padrões nos nomes de branches

Em termos de padrões e nomenclaturas no Git, esse ponto é importante mas não tão primordial assim. Mas acredito que é sempre sagaz ter um padrão de nomenclaturas e um nome explicativo nas branches.

Nomes de branches são compostos de 3 partes:

1 — Prefixos ou categoria do branch. Prefixos pré-definidos para criar uma branch, segue abaixo a lista:

  • docs/ apenas mudanças de documentação;
  • feature/ O nome já diz também o que é, uma nova feature que será adicionada ao projeto, componente e afins;
  • fix/ a correção de um bug;
  • perf/ mudança de código focada em melhorar performance;
  • refactor/ mudança de código que não adiciona uma funcionalidade e também não corrigi um bug;
  • style/ mudanças no código que não afetam seu significado (espaço em branco, formatação, ponto e vírgula, etc);
  • test/ adicionar ou corrigir testes.
  • improvement/ Uma melhoria em algo já existente, seja de performance, de escrita, de layout, etc.

2 — o que o branch faz em si.

3 — Código da tarefa no Jira. Ex.: SI20-348.

Exemplos de alguns nomes de branches que podem existir em nossa aplicação:

  • docs/padronizacao-commits-branches-git-SI20-348
  • feat/cadastro-veiculos-SI20-123
  • refactor/edicao-colaboradores-SI20-355
  • fix/busca-checklists-SI20-232

O código da tarefa no Jira é extremamente importante, ele ajuda autor e reviewer a localizarem o branch correto e também permite ao Jira linkar automaticamente um branch a uma tarefa, tornando o mesmo acessível a partir da tarefa:

Card da tarefa no Jira

Commits

Por que eu devo escrever boas mensagens de commit?

  • Uma mensagem de commit para o Git bem redigida é a melhor maneira de comunicar o contexto de uma alteração para outros desenvolvedores que estejam trabalhando no projeto. De fato, até para o seu "eu" do futuro.

  • As mensagens de commit podem comunicar adequadamente o motivo de uma alteração ter sido feita. Entender isso torna o desenvolvimento e a colaboração mais eficazes.

Você já tentou executar o comando git log em um de seus projetos antigos para ver as mensagens de commit "estranhas" que você usava desde o início de um projeto? Pode ser difícil entender a razão pela qual algumas alterações foram feitas no passado. Você vai desejar ter lido esse artigo antes :).

Como escrever boas mensagens de commit

Existem várias convenções usadas por equipes diferentes para escrever boas mensagens de commit. Descreverei aqui apenas algumas regras gerais e dicas para escrever mensagens de commit – você tem de decidir qual convenção deseja seguir. Se trabalha para uma empresa ou se contribui para o código aberto, é preciso se adaptar a convenção utilizada.

Algumas Convenções:

Para criar um histórico de revisão útil, as equipes primeiro devem concordar quanto a uma convenção a ser utilizada nas mensagens de commit. Isso também se aplica a projetos pessoais.

Padrões nos nomes dos Commits

Estrutura para um commit:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Vamos dissecá-la:

1 — type ou prefixos do commit: podem ser os mesmos utilizados para criar branches.

2 — scope: onde a alteração foi feita. Aqui, criamos nossos próprios scopes que, na maioria dos casos, refletem o nome de uma funcionalidade.

3 — subject: um resumo do commit. Deve utilizar o imperativo, como: faz, adiciona, altera, muda e etc.

4 — body: espaço utilizado para detalhar o que foi feito. É opcional.

5 — footer: onde colocamos as PLs (códigos das tarefas no Jira) e também alguma breaking change.

Onde tem <BLANK LINE> significa que temos que deixar uma linha em branco.

Prefixos dos Commits

  • docs: apenas mudanças de documentação;
  • feat: O nome já diz também o que é, uma nova feature que será adicionada ao projeto, componente e afins;
  • fix: a correção de um bug;
  • perf: mudança de código focada em melhorar performance;
  • refactor: mudança de código que não adiciona uma funcionalidade e também não corrigi um bug;
  • style: mudanças no código que não afetam seu significado (espaço em branco, formatação, ponto e vírgula, etc);
  • test: adicionar ou corrigir testes.
  • improvement: Uma melhoria em algo já existente, seja de performance, de escrita, de layout, etc.

Exemplo na prática

Aqui vou exemplificar uma sequência de alguns commits, comparando e mostrando a diferença entre apenas commitar e commitar usando commits semânticos:

Exemplo de commit semantico

Exemplo de commit semantico

Exemplo de commit semantico

Conclusão

A parte mais importante de uma mensagem de commit é o fato de que ela deve ser clara e significativa. No final, escrever boas mensagens de commit demonstra que você é um bom colaborador. Os benefícios de escrever boas mensagens de commit não se limitam apenas à sua equipe, mas se estendem a você mesmo e a colaboradores no futuro.

Fluxo de trabalho com Git

Uma dúvida muito comum a quem começa a usar o Git de maneira mais ativa é como organizar as branches, afinal, são muitos os problemas que um projeto pode enfrentar: De bugs urgentes que devem ser corrigidos, a criação de inúmeras features em conjunto com releases agrupando os deploys relativos a essas features.

Mas...como organizar tudo?

Artigo com conceito sobre a metodologia de trabalho e organização

GitHub Flow

  • GitHub Flow O fluxo de GitHub é um fluxo de trabalho leve e baseado no branch.

GitHub Flow

GitHub Flow

Gitflow

O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos e várias ramificações primárias.

GitFlow

Trunk-based Development (Desenvolvimento Baseado em Tronco)

O desenvolvimento baseado em tronco segue um ritmo rápido para entregar código à produção. Se o desenvolvimento baseado em tronco fosse como música, seria um staccato rápido — notas curtas e sucintas em rápida sucessão, com os commits de repositório sendo as notas. Manter commits e ramificações pequenas permite um ritmo mais rápido de merges e implementações.

Pequenas mudanças de um par de commits ou modificação de algumas linhas de código minimizam a sobrecarga cognitiva. É muito mais fácil para as equipes terem conversas significativas e tomar decisões rápidas ao revisar uma área limitada de código versus um conjunto extenso de alterações.

  • Youtube Alura - Git Flow vs Desenvolvimento baseado em tronco Git Flow vs Desenvolvimento baseado em tronco.

  • Desenvolvimento baseado em tronco x Gitflow Saiba por que essa prática de gerenciamento de controle de versão é prática comum entre as equipes de DevOps.

  • Atlassian - Desenvolvimento baseado em tronco Saiba por que essa prática de gerenciamento de controle de versão é prática comum entre as equipes de DevOps.

  • Principais características do trunk based development (desenvolvimento baseado em tronco)

    • As ramificações devem ter ciclos de vida curto, ficando sempre perto da ramificação principal.
    • Ter três ou menos ramificações ativas no repositório de código do aplicativo
    • A ramificação principal sempre precisa estar em estado de pronto para deploy em produção.
    • Permite a integração e revisão contínua de código.
    • Realizar revisões de código assíncronas.
    • Permite versões consecutivas de código de produção.
    • Os hotfixes precisam ser criados a partir da ramificação principal e serem devolvidos à ramificação principal.
    • Recomendado para aplicações: Micros serviços, single page application, Prova de conceito (POC), Sistemas distribuídos.
    • É preciso ter um processo de integração contínua, com etapas de testes automatizados e validadores de qualidade de código.
    • Desenvolvimento baseado em troncos e CI/CD.

O desenvolvimento baseado em tronco é hoje em dia o padrão para equipes de engenharia de alto desempenho, pois define e mantém uma cadência de lançamento de software usando uma estratégia simplificada de ramificação do Git. Além disso, o desenvolvimento baseado no central oferece às equipes de engenharia mais flexibilidade e controle sobre como entregam software para o usuário final.

Trunk Based Development

Ferramentas para gerenciamento GIT

  • Padronização Commits

  • Changelog

  • Versionamento

    • Versionamento Semântico 2.0.0 Como uma solução para este problema proponho um conjunto simples de regras e requisitos que ditam como os números das versões são atribuídos e incrementados.

  • Gitflow

    • Git Flow Git FLow Support for VS Code.
    • Git Flow Gitflow integration for VS Code.

  • Clientes Git GUI

    • Lista de Clientes Git GUI Os Melhores Clientes Git GUI para Windows, Linux e Mac.
    • Git History Extensão do VS Code, Histórico do Git, pesquisa e mais (incluindo git log).
    • Git Graph Extensão do VS Code, Visualize um Git Graph do seu repositório e execute facilmente as ações do Git a partir do gráfico.
    • SourceTree Simplicidade e poder em uma bela GUI Git para Mac e Windows (Atlassian).
    • Git Fork Um cliente git rápido e amigável para Mac e Windows.
    • GitKraken Inclui uma GUI Git intuitiva e uma poderosa CLI Git para Linux, Mac e Windows.

Referências

Autor

Made with 💙 by JUNIOR LIMA 👋 See my LinkedIn • GitHub @JuniorLima22

↑ voltar para o topo ↑