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:

Workflow simples em GIT
Workflow simples em GIT

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 test - comandos 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:

Workflow simple em Git com ação de correção de erro
Workflow simple em Git com ação de correção de erro

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.