Pular para o conteúdo principal

Tipos de Ramos do Controle de Versão

Um ramo é uma linha diferente na evolução que forma uma variação isolada e controlada do projeto.

Ramos resolvem vários problemas:

  • Permitem a execução simultânea de atividades diferentes e incompatíveis (ex.: codificação, teste, manutenção)
  • Organizam o esforço de implementação por finalidade, equipe, risco, restrição etc.
  • Isolam implementações arriscadas das que são certas e rápidas.

Se usada corretamente, a ramificação produz uma estrutura que consegue absorver todas as mudanças no projeto de maneira ordenada. Desde as emergenciais, que precisam ser atendidas com urgências e postas em produção, até alterações incertas, que podem se mostrar viáveis ou não com o tempo.

Tipos de Ramos

Existe mais de um tipo de ramo, mas as diferenças não estão na forma. Um modo de classificar as diferenças entre ramos é por sua finalidade:

  1. Ramo principal. É o primeiro e o mais importante ramo funcional de um projeto. Concentra todas as correções, funcionalidades, melhorias etc. que devem estar presentes na próxima grande versão a ser lançada em produção. Para que seja mantido sempre estável, apenas as implementações simples, rápidas e confirmadas são feitas diretamente sobre o ramo principal. No Subversion, o ramo principal é chamado de trunk. No Git, de master. No Mercurial, de default.
  2. Ramo dedicado (feature branch ou topic branch). Isola as implementações complexas, demoradas ou incertas que não podem ser feitas diretamente no ramo principal. Os casos que normalmente requerem um ramo dedicado são a implementação de um módulo/subsistema/componente ou alguma experimentação tecnológica/arquitetônica.
  3. Ramo de manutenção (release branch). Corresponde a uma versão lançada em produção que precisa ser corrigida, mas sem ter o conjunto de funcionalidades alterado. As correções são primeiro feitas no ramo de manutenção e depois repassadas aos demais ramos do projeto através de mesclagens.

A figura abaixo mostra uma padrão bastante comum dos ramos acima:

O ramo de manutenção é criado em um determinado momento para manter uma versão em produção. As correções são feitas primeiro no ramo de manutenção e passadas ao ramo principal por mesclagens.

O ramo dedicado foi criado para uma implementação complexa e incerta, que não pode ser feita diretamente no ramo principal. As mesclagens que descem do ramo principal para o ramo dedicado representam sincronizações periódicas necessárias para o ramo dedicado não ficar muito distante do que é feito no ramo principal. Isso levaria a um esforço muito grande de reintegração ao final. Falando nisso, a reintegração final é feita quando (e se) o ramo dedicado cumpriu seu papel e a implementação chegou ao fim com sucesso.

Duração dos Ramos

Além da finalidade, ramos podem ser classificados de acordo com sua duração. A duração de um ramo é o intervalo de tempo desde que é criado até o momento em que é incorporado em outro ramo ou abandonado:

Do ponto de vista da duração, há três tipos de ramos: de curta, média e longa duração.

Ramos de longa duração são usados por meses, anos ou por toda a vida do projeto. Um projeto possui poucos ramos de longa duração, geralmente apenas o ramo principal e alguns ramos de manutenção.

Ramos dedicados são ramos de média duração. Costumam ser usados por dias ou semanas e depois incorporados ao ramo principal ou simplesmente abandonados se os resultados não forem o esperado.

O tempo de um ramo de curta duração varia de minutos a alguns dias, apenas o suficiente para implementar uma mudança. Um ramo individual é o caso mais comum de ramo de curta duração. É formado naturalmente no controle de versão distribuído à medida que o desenvolvedor faz consolidações (commits) no seu repositório local. Possui geralmente uma única revisão que depois é combinada com outro ramo de maior duração através de mesclagem ou rebase.

Resumo

Resumo dos Tipos de Ramos
Ramo Finalidade Duração
Principal Mantém a configuração que se tornará a próxima versão maior a ser lançada em produção Longa
Dedicado Isola os casos de implementação demorada, complexa ou incerta Média
Manutenção Variação do projeto que mantém as funcionalidades de uma versão constantes enquanto defeitos são corrigidos Longa
Individual Variação local do projeto existente no repositório individual até a sincronização com o repositório oficial/remoto Curta

Estudo de Caso: Identificação dos Ramos do Git-Flow

A figura abaixo mostra a estratégia de ramificação usada no Git-Flow:

Tipos de Ramos Usados no Git-Flow
Principal develop (errado. Deveria ser master)
Manutenção master (errado), hotfixes e release branches
Dedicado feature branches

Apesar de não caber neste momento uma crítica mais detalhada do modelo de ramificação git-flow, alguns pontos precisam ser destacados:

  1. O ramo principal deveria ser master mas sua finalidade foi erroneamente deslocada para o ramo develop. O ramo master ficou inútil.
  2. Há ramos de manutenção demais. master e hotfixes são desnecessários.
  3. As setas que aparecem no grafo estão no sentido errado. Os apontamentos no controle de versão distribuído são para as revisões antecessoras.

Considerações Finais

Nem todos os projetos usam todos os tipos de ramos. Projetos web, por exemplo, possuem um único ramo de manutenção. Projetos tradicionais, por outro lado, possuem vários ramos de manutenção.

A natureza do projeto e o fluxo de trabalho empregado é que determinam quais os tipos de ramos necessários. Mais sobre isso em um próximo artigo!

Comentários

Comments powered by Disqus