Skip to content

Uso do Git no processo de desenvolvimento

O versionamento de código é uma tarefa essencial do fluxo desenvolvimento, ainda mais considerando times grandes, geograficamente distribuídos e cujas atividades podem ocorrer de forma paralela. Pensando nisso, padronizar a forma como os times interagem com a ferramenta de versionamento é primordial para um entendimento do que se está sendo feito.

Neste sentido, compartilhamos aqui um conjunto de boas práticas para o desenvolvimento.

Modelo de Ramificação

Os repositórios de nossa comunidade seguem dois modelos comuns de ramificação, o modelo conhecido como "GitHub Flow" e o modelo "Git Flow" a definição de qual modelo usar depende de cada time e finalidade do código, desta forma, verifique o histórico de commits antes de criar sua branch ou converse com alguém do time.

GitHub Flow

É um fluxo de trabalho leve e ágil, consideravelmente mais simples que o Git Flow, projetado para equipes que praticam a entrega e a integração contínuas (CI/CD). A ideia central é que a branch main deve estar sempre estável e pronta para ser implantada em produção a qualquer momento.

o GitHub Flow é a escolha ideal para projetos de desenvolvimento rápido, especialmente aplicações web e serviços que se beneficiam de um ciclo de vida de entrega contínua. Abaixo um exemplo de como o fluxo de desenvolvimento se dá na vida real.

---
title: Diagrama do GitHub Flow
---
gitGraph
   commit id: "v1.0" type: HIGHLIGHT

   branch feature/nova-funcionalidade
   checkout feature/nova-funcionalidade
   commit id: "Inicia dev"
   commit id: "Finaliza lógica"

   checkout main
   branch hotfix/ajuste-urgente
   checkout hotfix/ajuste-urgente
   commit id: "Corrige bug crítico"

   checkout main
   merge hotfix/ajuste-urgente tag: "v1.0.1"

   checkout feature/nova-funcionalidade
   commit id: "Adiciona testes"

   checkout main
   merge feature/nova-funcionalidade tag: "v1.1.0"

Para saber mais sobre o modelo, verifique a documentação oficial em GitHub Flow.

Git Flow

Talvez uma das metodologias main conhecidas pelo mundo dev, trata-se de um modelo robusto de gerenciamento de ramificações (branches) para projetos de software que utilizam o Git. Criado por Vincent Driessen, ele estabelece um fluxo de trabalho rigoroso, ideal para projetos com ciclos de lançamento agendados e que precisam manter uma versão de produção estável e uma de desenvolvimento em paralelo.

Sua estrutura se baseia na interação entre diferentes tipos de branches, cada uma com uma finalidade específica. Abaixo um diagrama com exemplo de ramificações usando este modelo:

---
title: Diagrama do Fluxo de Trabalho Git Flow
---
gitGraph
    %% 1. Inicialização com as branches main e develop
    checkout main
    commit id: "Initial Commit"
    branch develop

    %% 2. Desenvolvimento de uma feature
    checkout develop
    branch feature/nova-funcionalidade
    checkout feature/nova-funcionalidade
    commit id: "feat: Adiciona lógica"
    commit id: "feat: Adiciona UI"
    checkout develop
    merge feature/nova-funcionalidade

    %% 3. Ciclo de Lançamento (Release)
    branch release/v1.0.0
    checkout release/v1.0.0
    commit id: "ci: Aumenta a versão"
    commit id: "fix: Ajusta bugs menores"

    %% Merge da release na main (com tag) e na develop
    checkout main
    merge release/v1.0.0 tag: "v1.0.0"
    checkout develop
    merge release/v1.0.0

    %% 4. Ciclo de Correção Urgente (Hotfix)
    checkout main
    branch hotfix/bug-critico
    checkout hotfix/bug-critico
    commit id: "fix: Corrige bug crítico"

    %% Merge do hotfix na main (com tag) e na develop
    checkout main
    merge hotfix/bug-critico tag: "v1.0.1"
    checkout develop
    merge hotfix/bug-critico

Para conhecer mais sobre o Git Flow, recomendamos a leitura deste excelente resumo que pode ser acessado no link a seguir Git Flow.

Gerenciando o git

  1. Criação de uma Branch:

    • Comece criando uma nova branch (ramificação) no repositório para cada nova funcionalidade, correção de bug ou tarefa que você estiver trabalhando. Geralmente, as branches são nomeadas de maneira descritiva.

      git checkout -b nome-da-minha-feature

  2. Commits Incrementais:

    • Faça commits incrementais enquanto trabalha na sua branch. Cada commit deve representar um passo lógico no desenvolvimento da funcionalidade ou correção.

      git commit -am "Mensagem descritiva do commit"

  3. Abertura de Pull Request/Merge Request:

    • Assim que concluir o desenvolvimento na sua branch, abra um Pull Request (PR). Isso permite que os responsáveis(pares) revisem suas alterações antes de serem mescladas na branch principal (normalmente main ou master).

  4. Revisão de Código (Code Review):

    • Membros da equipe revisam seu código no Pull Request. Durante a revisão, podem ser feitos comentários, sugestões ou alterações adicionais podem ser solicitadas.

  5. Integração Contínua:

    • Utilize sistemas de integração contínua (CI) para garantir que as alterações propostas não quebrem o build e passem nos testes automaticamente.

  6. Merge na Branch Principal:

    • Após a revisão e a aprovação do Pull Request, a branch pode ser mesclada na branch principal. Isso pode ser feito pelo próprio autor do Pull Request ou por outro membro da equipe.

  7. Deploy:

    • Se houver um ambiente de produção, realize o deploy das alterações após a mesclagem na branch principal.

  8. Exclusão da Branch:

    • Após a mesclagem e o deploy bem-sucedido, a branch pode ser excluída, pois seu propósito foi cumprido.

Esse fluxo é cíclico e se repete para cada nova funcionalidade ou correção de bug, mantendo um histórico claro das alterações e permitindo que a equipe colabore de maneira eficiente. Vale ressaltar que o GitHub Flow é uma abordagem mais simplificada em comparação com outros modelos mais complexos, como Gitflow.

Branches

De forma a padronizar a nomenclatura usada na abertura de uma nova branch, seguimos a convenção a seguir:

  1. Features:

    • Devem conter o prefixo "feature", seguida do número da issue relacionada e uma descrição curta do que implementa. Abaixo um exemplo:
      feature/1215-descricao-curta-feature

  2. Bugfixes:

    • Devem conter o prefixo "bugfix", seguida do número da issue relacionada e uma descrição curta do que implementa. Abaixo um exemplo:
      bugfix/1216-descricao-curta-bugfix

  3. Hotfixes:

    • Devem conter o prefixo "hotfix", seguida do número da issue relacionada e uma descrição curta do que implementa. Abaixo um exemplo:
      hotfix/1217-descricao-curta-hotfix

Como diferenciar um hotfix de um bugfix?

A diferença entre bugfix e hotfix é que o segundo corrige erros em produção e o primeiro só no desenvolvimento

Pull Requests / Merge Requests

Os Pull Requests / Merge Requests deverão seguir o seguinte descritivo:

Tipo PR/MR - Descrição breve

Onde "Tipo PR/MR" Poderá ser "FEATURE REQUEST" e "FIX" e "Descrição breve" um resumo do que o PR implementa de forma simples e sucinta. Abaixo exemplos:

FEATURE REQUEST - Dashboard de boas vindas
FIX - Inconformidade ao atribuir valor total ao salvar entrada

Não esqueça de adicionar uma descrição detalhada para o PR/MR no campo destinado a isso em língua vernácula.

Tag

As etiquetas (tags) são usadas para acionar eventos dentro do fluxo. O uso das tags será feito no lançamento de um release candidate, ou seja, de um fechamento de versão e terá o seguinte padrão:

x.y.z

Onde:

- x - versão principal: terá o número incrementado uma vez que tenha sido instalado a versão anterior com os requisitos fechados em produção com garantia de funcionalidades operacionais.

- y - versão secundária: terá o número incrementado nas várias sprints de projetos.

- z - versão de correção: terá o número incrementado nas correções de erros de uma mesma sprint.

A regra é no incremento do número hierarquicamente superior (ou à esquerda), zera-se os inferiores (ou à direita).

Todos os artefatos gerados a partir do build da versão com a tag terá esse número de versão como referencia e deverá passar por todos os ambientes de implantação, ou seja, homologação e produção. Um release candidate pode ter seu ciclo de implantação interrompido.

Tipo de repositório

Será utilizado um repositório do tipo monorepo, ou seja, a compatibilidade sempre será mantida entre front e back que será desenvolvido ao mesmo tempo com todas as features sendo implementadas na mesma sprint no backend e no frontend. Essa decisão se baseia nas seguintes premissas:

Gerenciamento de Dependências Simplificado:

  • Consistência de Versões
  • Refatoração e Mudanças Globais
  • Compartilhamento de Código Facilitado
  • Melhor Rastreamento de Alterações e Histórico
  • Build e Teste Mais Eficientes
  • Padronização de Ferramentas e Configurações
  • Facilidade na Navegação e Descoberta
  • Simplificação do Versionamento