Três abordagens
Você pode usar uma dessas técnicas populares ou pode usá-las como base para criar a sua própria.
Fluxo do GitHub . A estratégia é usada pela equipe de serviço do GitHub. Os principais requisitos são os seguintes:
- Não há erros no código do branch master e ele deve estar pronto para ser implantado a qualquer momento;
- para começar a desenvolver um novo recurso, você precisa criar um branch de recurso no branch master e dar a ele um nome que seja óbvio para todos. Quando o trabalho está pronto, ele precisa ser mesclado no branch master por meio de uma solicitação de pull;
- após mesclar as alterações, você precisa implantá-las imediatamente no servidor.
Essa abordagem geralmente é usada para produtos com uma única versão que não é atualizada com muita frequência. Por exemplo, sites. Do lado positivo, essa abordagem torna mais fácil para os desenvolvedores entender e organizar seu trabalho. A principal desvantagem é que, se seu projeto for complexo o suficiente e atualizado com frequência, é melhor usar uma estratégia diferente.
GitFlow . É preciso dizer desde já que essa estratégia é discutível. Há muitos comentários positivos e negativos sobre ela.
O resultado final é o seguinte. Existem dois tipos de branches persistentes: o branch master, para entender como é a versão atual mais recente, e o branch de desenvolvimento, onde o desenvolvimento está ocorrendo. Existem três tipos de ramos temporários provenientes dele.
- Recurso, para adicionar novos recursos. Depois de concluir o trabalho, você precisa criar uma solicitação pull no branch de desenvolvimento.
- Solte para trabalhar em novas versões. É importante adicionar um número de versão ao título, isso o ajudará a evitar confusão e rastrear mudanças.
- Hotfix, para correções rápidas de bugs.
Esta abordagem é considerada uma das melhores para projetos onde várias versões para diferentes plataformas estão constantemente sendo desenvolvidas.
Em 2010, um texto do programador holandês Vincent Driessen " Um modelo de ramificação Git de sucesso " foi publicado, no qual ele falou pela primeira vez sobre GitFlow. O artigo se tornou bastante popular, uma tradução para o russo apareceu e o método foi adotado por muitas equipes.
Em 2020, o programador americano George Stoker publicou um artigo “ Por favor, pare de recomendar o Git Flow", Onde criticou o método como desatualizado e ineficaz nas realidades modernas. Driessen, em resposta, complementou seu texto de 2010 com um aviso, no qual admitia que seu método não era uma panaceia, mas apenas uma das opções para organizar o trabalho.
Fluxo de trabalho de bifurcação. Aqui, a abordagem é a seguinte: há um repositório original para mesclar todas as alterações e uma cópia dele, no qual outro desenvolvedor trabalha. A abordagem está muito próxima da ideologia do código aberto, seu objetivo é aproveitar todas as vantagens da comunidade de código aberto dentro do projeto. No entanto, a maior parte do fluxo de trabalho de ramificação está copiando GitFlow. Os ramos de recursos aqui irão se fundir com os repositórios de desenvolvedores locais. Assim, o desenvolvimento torna-se flexível mesmo para equipes muito grandes com contratados.
Entre aqueles que adotam essa abordagem está o Linux . Você pode oferecer suas próprias opções para alterar o código, mesmo para o núcleo do sistema. E essa abordagem parece funcionar de forma eficaz.
Pontos gerais
Seja qual for o conceito que você escolher, há pontos básicos que você deve seguir. Por exemplo, aqui estão as regras da Microsoft :
- não complique demais sua estratégia de filial;
- usar branches de recursos para todas as atualizações e correções de bugs;
- mesclar ramos de recursos em ramos principais usando solicitações pull;
- Mantenha a qualidade upstream e atualizada.
Uma estratégia baseada nessas ideias levará sua equipe a trabalhar com versões lógicas e fáceis de entender.
Aqui estão algumas diretrizes mais úteis.
Chame de simples e óbvio
Isso ajudará todos os membros da equipe a entenderem corretamente quem está trabalhando em quê. Também é aceitável incluir informações adicionais no nome do branch, por exemplo, o nome do criador. Este é o caso quando você não precisa inventar algo original. Nomes de ramos como “usuários”, “correção de bug”, “recurso”, “hotfix” são o que você precisa. Para ramificações que estão atrasadas, use sinalizadores especiais separados. Isso permitirá que a equipe entenda imediatamente o que está em jogo e sempre mantenha essas tarefas em mente a longo prazo.
Mesclar branches apenas por meio de uma solicitação pull
O mecanismo de solicitação pull provou ser lógico e bem pensado. Como esse processo leva tempo, você deve concordar dentro da equipe o que e em que prazo é esperado de todos os participantes da solicitação pull. Atribua as responsabilidades dos revisores e compartilhe-as com a equipe por meio da base de conhecimento interna.
Aqui estão algumas dicas específicas:
- de acordo com uma pesquisa da Microsoft , o número ideal de revisores é dois;
- se sua equipe já formou os princípios de revisão de código, siga-os e tente não quebrá-los;
- Uma solicitação pull funciona muito melhor quando mais membros da equipe são regularmente encarregados de revisar o código;
- Deixe descrições de seu trabalho com detalhes suficientes para que os revisores possam compreender rapidamente o contexto.
Configurar políticas da filial
Vale a pena gastar tempo ramificando políticas por vários motivos:
- desta forma, você pode isolar o trabalho atual do trabalho concluído dentro do branch principal;
- fazer restrições razoáveis ao determinar quem e quais mudanças podem ser feitas em ramos específicos;
- divulgar rapidamente métodos de trabalho eficazes.
Existem duas regras principais com base nas políticas que devem ser configuradas:
- revisores são adicionados automaticamente a uma solicitação pull no momento de sua criação. Você pode primeiro definir uma lista deles e, em seguida, editar à medida que avança;
- uma construção bem-sucedida é necessária para concluir a solicitação pull. O código derramado no branch principal deve ser compilado de forma limpa.
Mas o princípio mais importante ao criar sua estratégia de filial é este: você precisa pensar bem para que a equipe não tenha dúvidas sobre o significado desta ou daquela ação. Então, todos os dias em seu projeto serão produtivos.
Blog ITGLOBAL.COM - TI gerenciada, nuvens privadas, IaaS, serviços de segurança da informação para empresas: