Versionamento

Padrão para o GIT

Documentação de Git para o Time

Introdução

Esta documentação tem como objetivo padronizar o uso do Git em nosso time de desenvolvimento, seguindo boas práticas para gerenciamento de código e colaboração. O fluxo de trabalho adotado será o Git Flow, e as branches seguirão a convenção de nomes associadas às demandas na UITASK.

Fluxo de Trabalho (Git Flow)

Branches principais:

  • master: Contém o código em produção. Apenas alterações testadas e aprovadas devem ser mescladas aqui.
  • dev: Contém o código em desenvolvimento. Toda a implementação de novas funcionalidades e correções de bugs deve ser feita a partir dessa branch.

Git Flow:

Conheça abaixo nosso Git Flow baseado em sprints:

Git Flow
  • hotfix: Utilizada para correções rápidas e críticas em produção. As branches de hotfix são criadas a partir da branch master e, após a conclusão da correção, são mescladas de volta na master e na dev.
  • feature: Utilizada para o desenvolvimento de novas funcionalidades. As branches de feature são criadas a partir da branch sprintX e, após a conclusão do desenvolvimento, são mescladas de volta na sprintX.
  • sprint: Utilizada para o desenvolvimento de novas funcionalidades durante uma sprint. As branches de sprint são criadas a partir da branch dev e, após a conclusão do desenvolvimento, são mescladas de volta na dev.

Criação de uma nova branch:

Para qualquer ajuste ou nova funcionalidade, uma nova branch deve ser criada a partir da branch sprintX. A branch será nomeada seguindo o padrão da demanda da UITASK.

Nome da branch: TYPE-SIGLA-XXXX, onde:

  • TYPE é o tipo da branch, H para hotfix e F para feature.
  • SIGLA é a sigla da equipe ou projeto.
  • XXXX é o número da demanda na UITASK.

Exemplo de nome de branch:

  • H-STUD-0001 (para a demanda número 1 do time do STUDIO do tipo hotfix).
  • F-ERP-1024 (para a funcionalidade número 1024 do time do ERP do tipo feature).

Trabalho nas branches:

  • Faça todos os ajustes e desenvolvimentos necessários na branch criada.
  • Utilize commits pequenos e descritivos.
  • Nunca trabalhe diretamente nas branches master ou dev.

Pull Request (PR):

  • Após finalizar o desenvolvimento e realizar os testes locais, crie um Pull Request (PR) para a branch sprintX ou master dependendo se é hotfix ou feature.
  • O PR deve ser revisado por pelo menos um membro da equipe antes de ser aprovado e mesclado.
  • Inclua uma descrição clara no PR sobre as mudanças feitas, os testes realizados e qualquer outro detalhe relevante.

Resolução de conflitos:

  • Caso haja conflitos ao realizar o merge de um PR, resolve-os localmente e atualize o PR.
  • Evite forçar o merge sem antes resolver todos os conflitos de código.

Testes:

  • Antes de realizar um PR, certifique-se de que os testes estejam passando localmente e que o código esteja bem documentado.
  • O uso de ferramentas de integração contínua (CI) será feito para verificar se o código funciona corretamente ao ser mesclado nas branchs sprintX, dev ou master.

Fluxo de Desenvolvimento

1. Criação da branch:

Sempre crie uma nova branch com o nome seguindo o padrão:
TYPE-SIGLA-XXXX

git checkout sprint6
git pull origin sprint6
git checkout -b TYPE-SIGLA-XXXX

2. Commit e Push:

Realize commits frequentemente com mensagens claras, seguindo o formato: TYPE-SIGLA-XXXX - Titulo da demanda

git add .
git commit -m "TYPE-SIGLA-XXXX - Titulo da demanda"
git push origin TYPE-SIGLA-XXXX

3. Criação do Pull Request:

  • Após concluir o trabalho na branch, crie um Pull Request para a branch sprintX no GitHub.
  • Assegure-se de que o título do PR esteja claro e que ele descreva brevemente as mudanças.

4. Revisão de código:

  • Solicite uma revisão do código no PR por outro membro da equipe.
  • Realize as mudanças solicitadas durante a revisão e atualize o PR, se necessário.

5. Merge:

  • Após a aprovação, faça o merge do PR na branch sprintX no GitHub.
  • Evite o merge diretamente na master. A branch dev é onde o código será validado antes de ser promovido à produção.

6. Finalizando a branch:

  • Após o merge, delete a branch TYPE-SIGLA-XXXX tanto localmente quanto no repositório remoto:
git branch -d TYPE-SIGLA-XXXX
git push origin --delete TYPE-SIGLA-XXXX

Resumos das Regras:

  • Criação de branches: Sempre crie uma nova branch com o nome TYPE-SIGLA-XXXX.
  • Pull Requests: Sempre crie um PR para as sprintX e aguarde a revisão antes de mesclar.
  • Commits: Faça commits pequenos e claros. Nunca trabalhe diretamente nas branches principais (master ou dev).
  • Merge: O merge deve sempre ser feito para a branch sprintX primeiro, e depois validado na dev ou master após testes.

Observação: Para facilitar a padronização e garantir a consistência, todos os membros do time devem seguir este fluxo. Caso haja dúvidas ou sugestões para melhoria do processo, sintam-se à vontade para discutir.