Quase todos os sistemas de controle de versão atuais dão suporte a ramificações, sejam quais forem as linhas de trabalho que resultam de uma base de código central.
Uma estratégia de ramificação consiste em diretrizes que ajudam os desenvolvedores a organizar, escrever, mesclar e implantar código usando um sistema de controle de versão. A ramificação principal, que costuma ser chamada de linha principal, padrão ou tronco, serve como base a partir da qual os desenvolvedores podem criar suas próprias ramificações e trabalhar com autonomia. Compreender as várias estratégias de ramificação disponíveis é crucial para otimizar a colaboração e manter a qualidade do código em projetos de desenvolvimento de software.
Os benefícios de uma estratégia de ramificação
Colaboração
A ramificação permite que equipes de desenvolvedores colaborem com facilidade dentro de uma base de código central, mas as ramificações não precisam ficar isoladas. Os desenvolvedores podem usar alterações de outros desenvolvedores para colaboração em funções e garantir que a ramificação privada não se afaste muito da principal.
Trabalho isolado
Quando um desenvolvedor cria uma ramificação, o sistema de controle de versão cria uma cópia da base de código nesse ponto no tempo. As alterações na ramificação não afetam outros desenvolvedores da equipe. Esse é um lado bom, claro, porque funções em desenvolvimento podem criar instabilidade, e seria muito perturbador se todo o trabalho acontecesse na linha de código principal.
As ramificações não são boas apenas para recursos. As ramificações podem isolar a equipe de alterações arquitetônicas importantes, como atualização de estruturas, bibliotecas comuns, etc.
Três estratégias de ramificação para equipes ágeis
Os modelos de ramificação muitas vezes diferem entre as equipes e são tema de muito debate na comunidade de software. Um grande tema é quanto trabalho deve permanecer em uma ramificação antes de executar a mescla de volta à ramificação principal.
Ramificar liberações
Na ramificação de lançamentos, uma versão inteira fica contida em uma ramificação. Ou seja: no final do ciclo de desenvolvimento, o gerente de lançamento vai criar uma ramificação a partir da principal (por exemplo, "ramificação de desenvolvimento 1.1"). Todas as alterações na versão 1.1 precisam ser aplicadas duas vezes: uma vez na ramificação 1.1 e, em seguida, na linha de código principal. Lidar com duas ramificações é trabalho extra para a equipe. E é fácil esquecer de mesclar as duas ramificações. Ramificações de lançamento podem ser difíceis de gerenciar, pois muitas pessoas trabalham na mesma ramificação. Todo mundo já teve que mesclar várias alterações diferentes em uma única ramificação. Se você precisar ramificar um lançamento, crie uma ramificação que seja a mais parecida possível com a versão atual.
A ramificação de liberação é uma parte importante do suporte ao software com versão no mercado. Um único produto pode ter várias ramificações de liberação (por exemplo, 1.1, 1.2, 2.0) para apoiar o desenvolvimento sustentável. Não se esqueça de as alterações nas versões anteriores (ou seja, 1.1) podem precisar ser mescladas às ramificações de versões de liberação (ou seja, 1.2, 2.0). Confira o webinar abaixo para saber mais sobre como gerenciar ramificações de liberação com o Git.
Ramificação de funções
Ramificações de funções são, muitas vezes, acopladas a sinalizadores de função — "alternações" que ativam ou desativam uma função dentro do produto. Assim fica mais fácil implementar o código na ramificação principal e controlar quando a função é ativada, facilitando a implementação inicial do código bem antes de a função ser exposta aos usuários finais.
Outro benefício dos sinalizadores de função é que o código pode permanecer dentro da build, mas inativo enquanto estiver em desenvolvimento. Se algo der errado quando a função estiver ativada, um administrador do sistema pode reverter o sinalizador de função e retornar a um bom estado conhecido, em vez de precisar implementar uma nova build.
Ramificação de tarefa
Na Atlassian, focamos em um fluxo de trabalho de ramificação por tarefa. Toda organização tem uma maneira natural de dividir o trabalho em tarefas individuais dentro de um rastreador de itens, como o Jira. Os itens passam a ser o ponto de contato central da equipe para esse trabalho. A ramificação de tarefas, também conhecida como ramificação de itens, conecta diretamente esses itens ao código-fonte. Cada item é implementado na própria ramificação, com a chave do item incluída no nome da ramificação. É fácil ver qual código implementa qual item: basta procurar a chave do item no nome da ramificação. Com esse nível de transparência, é mais fácil aplicar alterações específicas à ramificação principal ou a uma ramificação de lançamento legada mais antiga.
Como o método ágil é centrado em torno de histórias de usuário, as ramificações de tarefa complementam o desenvolvimento ágil. Cada história de usuário (ou atualização de segurança) fica dentro de sua própria ramificação, tornando mais fácil ver quais itens estão em andamento e quais estão prontos para lançamento.
Desafios da ramificação
Todos já tivemos o trabalho de integrar várias ramificações em uma solução sensata. Tradicionalmente, os sistemas de controle de versão centralizados, como o Subversion, tornaram a mesclagem uma operação muito difícil. Mas sistemas de controle de versão mais novos, como Git e Mercurial, adotam uma abordagem diferente para monitorar versões de arquivos em diferentes ramificações.
As ramificações tendem a durar pouco tempo. Por isso, são mais fáceis de mesclar e mais flexíveis em toda a base de código. Com a mesclagem frequente e automática de ramificações como parte da integração contínua (IC), além do fato de que ramificações de curta duração têm menos alterações, o "inferno da mesclagem" vira coisa do passado para as equipes que usam o Git e o Mercurial.
É isso que torna a ramificação de tarefa tão incrível!
Conclusão…
Um sistema de controle de versão só pode ir até aí em relação a afetar o resultado de uma mesclagem. Testes automatizados e integração contínua também são críticos. A maioria dos servidores de IC pode colocar novas ramificações sob teste automaticamente, reduzindo drasticamente o número de "surpresas" após a mesclagem final upstream e ajudando a manter a linha de código principal estável.
