Ramifique recursos em seu caminho para a grandeza

Ou ramifique tarefas em seu caminho. Ou ramifique liberações. Você escolhe.

Dan Radigan Dan Radigan

Quase todos os sistemas de controle de versão atuais dão suporte a ramificações – independentemente das linhas de trabalho que resultam de uma base de código central. Dependendo do seu sistema de controle de versão, a ramificação principal pode ser chamada de mestre, principal, padrão ou central. Os desenvolvedores podem criar suas próprias ramificações da linha principal do código e trabalhar de forma independente ao lado dela. 

Por que se preocupar com a ramificação?

A ramificação permite que equipes de desenvolvedores colaborem facilmente dentro de uma base de código central. 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. Isso é bom, obviamente, porque recursos em desenvolvimento podem criar instabilidade, e seria altamente perturbador se todo o trabalho acontecesse na linha de código principal. Mas as ramificações não precisam viver em confinamento. Os desenvolvedores podem facilmente usar alterações de outros desenvolvedores para colaboração em recursos e para garantir que sua ramificação privada não divirja muito da principal.

Dica profissional

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 se executar a mescla de volta à ramificação principal. 

Ramificar liberações

A ramificação de liberações refere-se à ideia de que uma liberação está contida inteiramente dentro de uma ramificação. Isto significa que, no final do ciclo de desenvolvimento, o gerente de liberação 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. Trabalhar com duas ramificações é trabalho extra para a equipe e é fácil de esquecer de mesclar as duas ramificações. Ramificações de liberação podem ser difíceis de gerenciar, pois muitas pessoas estão trabalhando na mesma ramificação. Todos já tivemos o trabalho de mesclar muitas alterações diferentes em uma única ramificação. Se você precisar fazer uma ramificação de liberação, crie a ramificação do modo mais próximo possível da atual. 

Warning:

Release branching is an important part of supporting versioned software out in the market. A single product may have several release branches (e.g., 1.1, 1.2, 2.0) to support sustaining development. Keep in mind that changes in earlier versions (i.e., 1.1) may need to be merged to later release branches (i.e., 1.2, 2.0). Check out our webinar below to learn more about managing release branches with Git.

Ramificação de recurso

Ramificações de recurso são, muitas vezes, acoplados a sinalizadores de recurso – "alternações" que ativam ou desativam um recurso dentro do produto. Isso torna mais fácil a implantação do código na ramificação principal e o controle quando o recurso é ativado, facilitando a implantação inicial do código bem antes de o recurso ser exposto aos usuários finais. 

Dica profissional:

Another benefit of feature flags is that the code can remain within the build but inactive while it's in development. If something goes awry when the feature is enabled, a system admin can revert the feature flag and get back to a known good state rather than have to deploy a new build.

Ramificação de tarefa

At Atlassian, we focus on a branch-per-task workflow. Every organization has a natural way to break down work in individual tasks inside of an issue tracker, like Jira Software. Issues then becomes the team's central point of contact for that piece of work. Task branching, also known as issue branching, directly connects those issues with the source code. Each issue is implemented on its own branch with the issue key included in the branch name. It’s easy to see which code implements which issue: just look for the issue key in the branch name. With that level of transparency, it's easier to apply specific changes to master or any longer running legacy release branch.

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 correção de erros) fica dentro de sua própria ramificação, tornando mais fácil ver quais questões estão em andamento e quais estão prontas para liberação. Para um entendimento mais abrangente sobre a ramificação de tarefa (às vezes chamada de ramificação de questão ou ramificação por questão), pegue a pipoca e confira o webinar abaixo – um dos nossos mais populares. 

Conheça agora o gêmeo do mal da ramificação: a mesclagem

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 ser de curta duração, tornando-as mais fáceis de mesclar e mais flexíveis em toda a base de código. Entre a capacidade de frequente e automaticamente mesclar ramificações como parte da integração contínua (CI) e o fato de que ramificações de curta duração simplesmente têm menos alterações, o "inferno da mesclagem" é coisa do passado para as equipes que usam Git e Mercurial.

É isso que torna a ramificação de tarefa tão incrível! 

Validar, validar, validar

A version control system can only go so far in affecting the outcome of a merge. Automated testing and continuous integration are critical as well. Most CI servers can automatically put new branches under test, drastically reducing the number of "surprises" upon the final merge upstream and helping to keep the main code line stable.