Neste artigo apresento uma proposta para um fluxo de trabalho simples usando a ferramenta de gestão de versão de código fonte padrão do mercado, um Git workflow.

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.

Git workflow simples

A imagem a seguir apresenta um diagrama que resume o trabalho regular, de forma simplificada, em um projeto de desenvolvimento com versionamento de código usando Git:

Git Workflow simples

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

  • Criação do repositório
$ git init
  • Commit inicial no branch master
$ git add .
$ git commit -m 'Initial commit'
  • Proteger o branch master para que não seja possível fazer push direto nele.
  • Criação do branch dev para ser utilizado pelo desenvolvimento
$ git checkout -b dev
  • Realizar os commits no branch dev
$ git add .
$ git commit -m 'Minha nova funcionalidade'

# push para o repositório central sempre que necessário
$ git push origin dev
  • Ao chegar em um momento de realizar testes para publicação da aplicação em produção, criar o branch test:
    • Caso o branch ainda não exista, crie o mesmo a partir de dev:
$ git checkout -b test
  • Fazer o merge de dev em test, enviar para o repositório central e realizar o deploy no servidor de testes
$ git checkout test
$ git merge dev
$ git push origin test
  • Se todos os testes passarem, fazer o merge de test em master, criar tag de versão, então publicar em produção
$ git checkout master
$ git merge test
$ git tag 'v.0.1.0'
$ git push origin master
$ git push --tags
  • Continuar o desenvolvimento em dev
$ git checkout dev
  • Novo ponto de estabilidade para publicação em produção, novamente fazer o merge de dev em test
$ git checkout test
$ git merge dev
  • Caso algum erro/falha seja encontrado no teste, corrigir em dev
  • Após correções, novo merge de dev em testcomandos anteriores
  • Após todos os testes serem aceitos, merge de test em master, tag de versão, publicar em produção – comandos de publicação em produção e master explicados acima
  • 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 workflow simples com bugix

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

  • Inicia-se um novo branch para a correção do bug, neste exemplo o branch é chamado de bugfix-0.1.0
  • Este novo branch deve ser iniciado a partir do master pois o branch dev já está com alterações que ainda não foram testadas
$ git checkout master
$ git checkout -b bugfix-0.1.0
  • Faz-se os commits necessários para a correção/alteração na branch bugfix-0.1.0
  • 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 para dev, com o objetivo de não perder a correção nas versões futuras que estão em desenvolvimento
$ git add .
$ git commit -m 'Correções implementadas'

# testes realizados
$ git checkout master
$ git merge bugfix-0.1.0
$ git push origin master
$ git checkout dev
$ git merge bugfix-0.1.0
$ git push origin dev
  • Neste ponto é possível excluir o ramo de bugfix se desejado, pois as alterações terão sido incorporadas no branch dev

Considerações finais

Este é um workflow 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.

Eu diria que funciona bem, principalmente, para desenvolvedores solo.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre Git

Como resolver o erro fatal refusing to merge unrelated histories
O erro fatal refusing to merge unrelated histories é lançado ao tentar fazer o merge automático de projetos que possuem históricos Git diferentes. Desde o Release 2.9.0 o Git não permite esta operação. O erro fatal: refusing …
Como configurar username e email por projeto com Git
Se você trabalha com diferentes usuários em projetos pessoais e de trabalho, é interessante configurar seu username e email no Git de maneira local, por projeto, para que seja corretamente rastreado no Github, Gitlab e …
Instalando Git no Windows, Linux e MacOS
O sistema de versionamento de software Git não vem instalado por padrão nos sistemas operacionais Linux, Windows e MacOS. Mesmo se ele já tiver sido instalado, é uma boa ideia atualizar para a versão mais …
Repositórios de dados abertos para programadores
Awesome Data Table References é um repositório de minha responsabilidade, onde faço curadoria de referências para tabelas de dados abertos de instituições e órgãos brasileiros e mundiais. Sempre que é necessário criar um campos de …
O que é Git
Você conhece o conceito geral e sabe o que é o GIT? Este que é, de longe, o sistema de controle de versão moderno mais usado no mundo atualmente. O Git é um projeto de …
Cache temporário das credenciais GIT – username e password
Existem situações em que você precisa trabalhar com um repositório GIT usando o protocolo HTTPs e não pode armazenar permanentemente as credenciais de usuário na configuração local. Uma solução é armazenar em um cache temporário …

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *