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 de usuário ou correção de erros 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 problema ajuda as equipes a entregar o código de trabalho em um fluxo contínuo
- Como o fluxo de trabalho é para os desenvolvedores
- Como ele se integra à sua integração contínua existente e às práticas de revisão de código
- Prós e contras básicos a 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ês lidam com números de versão em todas essas ramificações? Como diferenciam 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 analisam o repositório, fica muito claro qual ramificação é essa. Você pode usar qualquer convenção de nomenclatura para sua equipe – apenas inclua o número de versão em algum lugar.
P: Em seus 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. Apenas certifique-se de seguir a etiqueta básica da ramificação compartilhada, por exemplo, não trocar de base, e, normalmente, evitar execuções na cópia local da ramificação, o que causará problemas para a outra pessoa. Outra opção é solicitar que cada colaborador crie sua própria ramificação para o problema e mesclem todas com frequência. A convenção de nomenclatura para isso pode ser
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 suas 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 a refatoração 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.
