Error Tracking

Para uma gestão eficiente de um projeto de desenvolvimento de software, além do uso elementar de uma ferramenta de versionamento, é importante definir uma padronização de organização para a equipe. Neste artigo é proposto para git fluxo de trabalho simples.

Git fluxo de trabalho simples

A imagem a seguir apresenta um diagrama que resume o trabalho regular, de forma simplificada, em um projeto de desenvolvimento com git:



git-flow-simples

A sequência a seguir descreve este fluxo de trabalho, considerando um caminho sem exceções no andamento do desenvolvimento:

  • Criação do repositório
  • Pode-se fazer um commit inicial no branch master
  • Proteção no branch master
  • Criação do branch dev para ser utilizado pelo desenvolvimento
  • Commits realizados no dev
  • Ao chegar em um momento de testes para publicação, criar o branch test
  • Fazer o merge de dev em test
  • Se todos os testes passarem, fazer o merge de test em master, criar tag de versão, então publicar em produção
  • Continuar o desenvolvimento em dev
  • Novo ponto de estabilidade para publicação em produção, novamente fazer o merge de dev em test
  • Caso algum erro/falha seja encontrado no teste, corrigir em dev
  • Após correções, novo merge de dev em test
  • Aceitos todos os testes, merge de test em master, tag de versão, publicar em produção
  • Continuar o fluxo de trabalho descrito

Desta maneira, consideramos que a versão em produção será sempre igual à última tag do branch master. A última versão no ambiente de testes será sempre a última entrada (HEAD) no ramo test. Enquanto o desenvolvimento continua trabalhando no branch dev com as novas funcionalidades a serem implementadas.

Git fluxo de trabalho simples e correções de erro

Note que ainda é possível criar ramificações a partir do master caso algum erro seja identificado na versão de produção, enquanto o desenvolvimento de novas funcionalidades avançou, o diagrama a seguir exemplifica este contexto:

git-flow-simples-bugfix

Portanto, quando um bugfix é necessário na versão que está rodando em produção:

  • Inicia-se um novo branch, neste exemplo chamado de bugfix-0.1.0
  • Faz-se os commits necessários para a correção/alteração
  • Testa-se, podendo ou não enviar ao branch test, neste exemplo consideramos um teste direto do bugfix
  • Faz-se o merge de bugfix para master, e também de bugfix para dev, com o objetivo de não perder a correção nas versões futuras
  • Neste ponto é possível excluir o ramo de bugfix se desejado, pois as alterações terão sido incorporadas no branch dev

Lembrando que este é um fluxo de trabalho muito simples, porém que atende a projetos com equipes pequenas ou projetos onde o desenvolvimento de funcionalidades e entregas ocorre de forma “linear” ou sequencial.

Pin It on Pinterest

Share This

Share This

Share this post with your friends!