Trabalho em equipe sem confusão: entendendo as estratégias de ramificação no Git

Introdução

O Git se tornou o padrão da indústria de fato para sistemas de controle de versão no desenvolvimento de software. Você deve primeiro ler meu artigo sobre o que é Git e como começar. Você leu isso? Excelente, vamos em frente! Goste ou não, esta ferramenta criada por Linus Tovalds não vai se aposentar. Então, faz sentido falar sobre como as equipes distribuídas trabalham com o Git e qual estratégia de ramificação elas devem escolher para isso. Esta não é uma pergunta inconsequente. Ao montar uma nova equipe de desenvolvimento que não trabalhou anteriormente, a estratégia de ramificação costuma ser uma das primeiras coisas a decidir. E algumas pessoas vão espumar pela boca para provar que uma estratégia é melhor que outra. Então, quero transmitir a você algumas informações gerais sobre eles.

As estratégias de ramificação são necessárias?

Eles são realmente necessários. Muito necessário. Porque se a equipe não concordar em algo, cada membro da equipe fará o que quiser:

• trabalhando em qualquer ramo
• fundindo-se em outros ramos arbitrários
• excluindo alguns ramos
• criando novos
• e assim cada membro da equipe atuará em um fluxo não gerenciado.

É por isso que temos três estratégias a serem consideradas abaixo. Vamos!

Fluxo do GitHub

Essa estratégia de ramificação, curiosamente, é preferida no GitHub :) Ela vem com um conjunto de regras :

1. O código na ramificação master não deve ser quebrado. Deve estar pronto para ser implantado a qualquer momento. Ou seja, você não deve colocar um código que o impeça de construir o projeto e implantá-lo no servidor.
2. Ao planejar trabalhar em uma nova funcionalidade, você precisa criar uma nova ramificação de recurso com base na ramificação principal e dar a ela um nome significativo. Confirme seu código localmente e envie regularmente suas alterações para a mesma ramificação no repositório remoto.
3. Abra uma solicitação pull (você pode ler sobre solicitações pull aqui ) quando achar que o trabalho está pronto e pode ser mesclado na ramificação master (ou se não tiver certeza, mas deseja obter feedback sobre o trabalho realizado).
4. Depois que o novo recurso na solicitação pull for aprovado, ele poderá ser mesclado na ramificação principal.
5. Quando as alterações são mescladas na ramificação principal, elas devem ser implantadas no servidor imediatamente.

De acordo com o GitHub Flow, antes de começar a trabalhar em algo novo, seja uma correção ou um novo recurso, você precisa criar um novo branch baseado em master e dar a ele um nome adequado. Em seguida, começa o trabalho de implementação. Você deve enviar commits constantemente para o servidor remoto com o mesmo nome. Ao concluir que está tudo pronto, você precisa criar um pull request para o branch master. Então, pelo menos uma, ou melhor ainda, duas pessoas devem olhar para este código antes de clicar em "Aprovar". Normalmente, o líder da equipe do projeto e uma segunda pessoa devem definitivamente dar uma olhada. Em seguida, você pode concluir a solicitação pull. O GitHub Flow também é conhecido por impulsionar a entrega contínua (CD) em projetos. Isso ocorre porque, quando as alterações vão para a ramificação master, elas devem ser implantadas no servidor imediatamente.

GitFlow

A estratégia anterior (GitHub Flow) não é muito complicada em sua essência. Existem dois tipos de branches: master e feature branches. Mas o GitFlow é mais sério. Pelo menos, a imagem acima deve deixar isso claro :) Então, como essa estratégia funciona? Em geral, o GitFlow consiste em duas ramificações persistentes e vários tipos de ramificações temporárias. No contexto do GitHub Flow, o branch master é persistente e os demais são temporários. Ramos persistentes

• mestre: Ninguém deve tocar ou empurrar nada para este galho. Nesta estratégia, master representa a versão estável mais recente, que é usada na produção (ou seja, em um servidor real)
• desenvolvimento: O ramo de desenvolvimento. Pode ser instável.

O desenvolvimento acontece usando três ramificações temporárias auxiliares :

1. Ramificações de recursos — para desenvolver novas funcionalidades.
2. Ramificações de lançamento — para preparar o lançamento de uma nova versão do projeto.
3. Ramos Hotfix — para corrigir rapidamente um bug encontrado por usuários reais em um servidor real.

Ramos de recursos

Ramificações de recursos são criadas por desenvolvedores para novas funcionalidades. Eles sempre devem ser criados com base no ramo de desenvolvimento. Depois de concluir o trabalho na nova funcionalidade, você precisa criar uma solicitação pull para a ramificação de desenvolvimento. Claramente, equipes grandes podem ter mais de uma ramificação de recurso por vez. Dê uma olhada na figura no início da descrição da estratégia GitFlow.

Ramos de lançamento

Quando o conjunto necessário de novos recursos estiver pronto na ramificação de desenvolvimento, você poderá se preparar para o lançamento de uma nova versão do produto. Uma ramificação de lançamento, criada com base na ramificação de desenvolvimento, nos ajudará com isso. Ao trabalhar com o branch de lançamento, você precisa encontrar e corrigir todos os bugs. Quaisquer novas alterações necessárias para estabilizar a ramificação de lançamento também devem ser mescladas novamente na ramificação de desenvolvimento. Isso é feito para estabilizar o ramo de desenvolvimento também. Quando os testadores dizem que a ramificação é estável o suficiente para uma nova versão, ela é mesclada na ramificação principal. Posteriormente, uma tag, à qual é atribuído um número de versão, é criada para este commit. Para ver um exemplo, veja a foto no início da estratégia. Lá você verá a Tag 1.0— esta é apenas uma tag que indica a versão 1.0 do projeto. E, finalmente, temos o ramo hotfix.

Ramos de correção

As ramificações de hotfix também servem para liberar uma nova versão para a ramificação principal. A única diferença é que esses lançamentos não são planejados. Existem situações em que os bugs entram na versão lançada e são descobertos no ambiente de produção. Veja o iOS: assim que uma nova versão é lançada, você recebe imediatamente várias atualizações com correções de bugs encontrados após o lançamento. Assim, precisamos corrigir rapidamente um bug e lançar uma nova versão. Em nossa foto, isso corresponde à versão 1.0.1. A ideia é que o trabalho em novas funcionalidades não precise parar quando for necessário corrigir um bug em um servidor real (ou como dizemos, "em prod" ou "em produção"). A ramificação hotfix deve ser criada a partir da ramificação mestre, pois representa o que está sendo executado atualmente na produção. Assim que a correção do bug estiver pronta, ele é mesclado no mestre e uma nova tag é criada. Assim como preparar um branch de lançamento, um branch de hotfix também deve mesclar sua correção de volta ao branch de desenvolvimento.

Fluxo de trabalho de bifurcação

No fluxo de trabalho de bifurcação, o desenvolvimento envolve dois repositórios:

1. O repositório original, no qual todas as alterações serão mescladas.
2. Um repositório fork. Esta é uma cópia do repositório original, pertencente a outro desenvolvedor que deseja fazer alterações no original.

Parece um pouco estranho até agora, certo? Qualquer um que já tenha encontrado o desenvolvimento de código aberto já está familiarizado com essa abordagem. Essa estratégia oferece a seguinte vantagem: o desenvolvimento pode acontecer em um repositório bifurcado sem conceder permissões para desenvolvimento conjunto na ramificação original. Naturalmente, o proprietário do repositório original tem o direito de rejeitar as alterações propostas. Ou para aceitá-los e mesclá-los. Isso é conveniente tanto para o proprietário do repositório original quanto para o desenvolvedor que deseja ajudar a criar o produto. Por exemplo, você pode sugerir alterações no kernel do Linux . Se Linus decidir que fazem sentido, as alterações serão adicionadas (!!!).

Um exemplo do fluxo de trabalho de bifurcação

O fluxo de trabalho de bifurcação é aplicado no GitHub quando há uma biblioteca que você deseja usar. Ele tem um bug que o impede de usá-lo totalmente. Suponha que você mergulhe profundamente no problema e conheça a solução. Usando o fluxo de trabalho de bifurcação, você pode corrigir o problema sem direitos para trabalhar no repositório original da biblioteca. Para começar, você precisa selecionar algum repositório, por exemplo, o Spring Framework . Encontre e clique no botão "Fork" no canto superior direito: isso levará algum tempo. Em seguida, uma cópia do repositório original aparecerá em sua conta pessoal, o que indicará que é uma bifurcação:Agora você pode trabalhar com este repositório normalmente, adicionando alterações ao branch master e, quando tudo estiver pronto, você pode criar uma solicitação pull para o repositório original. Para fazer isso, clique no botão New pull request :

Qual estratégia escolher

O Git é uma ferramenta flexível e poderosa que permite trabalhar usando uma ampla variedade de processos e estratégias. Porém, quanto mais opções você tiver, mais difícil será decidir qual estratégia escolher. É claro que não há uma resposta única para todos. Tudo depende da situação. Dito isto, existem várias diretrizes que podem ajudar com isso:

1. É melhor escolher a estratégia mais simples primeiro. Mude para estratégias mais complexas somente quando necessário.
2. Considere estratégias que tenham o menor número possível de tipos de ramificação para desenvolvedores.
3. Veja os prós e os contras das várias estratégias e, em seguida, escolha a que você precisa para o seu projeto.

Isso é tudo que eu queria dizer sobre estratégias de ramificação no Git. Obrigado pela atenção :) Siga-me no GitHub , onde costumo postar minhas criações envolvendo diferentes tecnologias e ferramentas que utilizo em meus trabalhos.