Livres de congelamentos de códigos não muito bem feitos e megafusões massivas que contaminam o controle de versão centralizado, os desenvolvedores podem isolar o trabalho em andamento e criar em fatias verticais estreitas com facilidade. Ramificação e mesclagem são tão fáceis com Git que muitas equipes estão fazendo novas ramificações para cada história do usuário ou atualização de segurança que implementam. Este modelo está se tornando rapidamente o novo padrão ouro para equipes ágeis – e por uma boa razão!
Pegue uma pipoca e se sente para ver um dos webinars mais populares que a gente oferece. Você vai aprender:
- Como um modelo de ramificação por item ajuda as equipes a oferecer código funcional em um fluxo contínuo
- Como é o fluxo de trabalho para desenvolvedores
- Como ele se integra à integração contínua existente e às práticas de revisão de código
- Pontos a favor/contra para considerar ao avaliar este modelo
Assista e aprenda
P & R
Ótimo material, não?
Agora, se for como eu, você quase nunca vê a parte de perguntas e respostas de um webinar. Tudo bem, pode admitir. Por isso, transcrevi algumas perguntas para você ler conforme for conveniente.
P: Como você lida com números de versão em todas essas ramificações? Como diferencia essas linhas de código?
R: As equipes normalmente nomeiam a ramificação de acordo com a versão correspondente. Por exemplo, quando a equipe que faz o Stash estava preparando a versão 2.9, eles criaram uma ramificação estável chamada stash-2.9. Então, quando eles a veem no repositório, fica muito claro qual ramificação é essa. Você pode usar qualquer convenção de nomenclatura para a equipe, apenas inclua o número de versão em algum lugar.
P: Nos exemplos, você tinha uma pessoa trabalhando em cada ramificação. Qual é a estrutura de ramificação e a convenção de nomenclatura corretas para quando duas pessoas estão trabalhando em uma história?
R: É possível ter duas pessoas trabalhando na mesma ramificação do item. Apenas não se esqueça de seguir a etiqueta básica de ramificação compartilhada, por exemplo, não trocar de base, e costuma evitar execuções na cópia local da ramificação, o que vai causar problemas para a outra pessoa. Outra opção é solicitar que cada colaborador crie a própria ramificação para o item e mesclar todas com frequência. A convenção de nomenclatura para isso pode ser <nome/iniciais>-<chave do elemento>-<descrição> (por exemplo., sarah-DEV-1234-nome-da-empresa-com-erro-na-página-inicial), que é mais ou menos o mesmo que usamos para ramificações de um único desenvolvedor.
P: Como você lida com as dependências se não está mesclando todas as alterações em uma única ramificação assim que ela é feita em uma ramificação de desenvolvimento?
R: Se as partes dependentes estão em andamento, então os desenvolvedores que estão trabalhando em cada parte do código devem mesclar as alterações frequentemente. E é possível fazer isso no Git sem precisar mesclar a ramificação em uma ramificação centralizada em primeiro lugar, você e o outro desenvolvedor só podem mesclar as ramificações diretamente. A outra opção é usar a ramificação de integração compartilhada sobre a qual falamos hoje.
P: Há algum tempo, Martin Fowler argumentou contra a ramificação de recursos, dizendo que isso impede o refatoramento e que enquanto a ramificação de recurso está ativa, você faz uma criação contínua e não uma integração contínua.
R: Sim, já li a publicação que ele fez sobre esse assunto. Foi há bastante tempo – talvez 2008 ou 2009. Acho que as oportunidades para execução de IC em ramificações de recursos avançaram muito desde então. E como eu disse na parte de "considerações" desse webinar, uma abordagem de ramificação por item significa que você não está fazendo IC pura. Você está fazendo criação e testes contínuos, mas não integração contínua. Você pode chegar perto de ter IC pura, no entanto, apenas ao incluir uma ramificação de integração compartilhada no esquema de ramificação.
