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

Introdução

O Git se tornou o padrão de fato da indústria para controle de versão na criação de software. Para saber o que é git e como começar, primeiro leia meu artigo sobre ele. Você leu isso? Ótimo, vamos em frente! Goste ou não, o instrumento que Linus Towalds criou não vai se aposentar. Portanto, faz sentido falar sobre como as equipes distribuídas funcionam no git e qual estratégia de ramificação escolher para isso. E esta não é uma questão inútil. Freqüentemente, em uma situação em que uma nova equipe de desenvolvedores que não colaboraram entre si é montada, a estratégia de ramificação é uma das primeiras coisas que precisam ser decididas. E haverá quem espumará pela boca para provar que uma estratégia é melhor que outra. Portanto, quero transmitir a vocês informações sobre o que geralmente são.

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

Mas eles são necessários e ainda são necessários. Porque se você não concordar em alguma coisa na equipe, acontece que cada um fará o que quiser:

• trabalhar no ramo que desejar;
• fundir-se em outros ramos que desejar;
• exclua alguns ramos;
• crie novos;
• e assim por diante – cada um dos membros da equipe está em um fluxo descontrolado.

Portanto, abaixo estão três estratégias. Ir!

Estratégia de fluxo do GitHub

A estratégia de ramificação, por mais estranha que seja, é preferida no GitHub :) Anexo a ela está um conjunto de regras que precisam ser seguidas:

1. O código na ramificação master deve estar intacto e pronto para ser implantado a qualquer momento (ou seja, você não pode colocar código lá 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 (ramificação de recurso) baseada na ramificação mestre e dar a ela um nome significativo. Confirme seu código localmente e envie regularmente suas alterações para a mesma ramificação em um repositório remoto.
3. Abra uma solicitação pull (você pode ler o que é uma solicitação pull aqui ) quando houver uma sensação clara de que o trabalho está pronto e pode ser mesclado no branch master (ou se você não tiver certeza, mas quiser obter feedback sobre o trabalho feito).
4. Depois que um novo recurso em uma solicitação pull for aprovado, ele poderá ser mesclado no branch master.
5. Quando as alterações são mescladas no branch master, elas precisam ser implantadas no servidor imediatamente.

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

Estratégia GitFlow

A estratégia anterior (GitHub Flow) não era essencialmente muito complexa. Existem dois tipos de ramificações: ramificações mestre e ramificadas. Mas o GitFlow é mais sério. Pelo menos você pode entender isso pela imagem acima. Então, como funciona essa estratégia? Em geral, o GitFlow consiste em duas ramificações permanentes e vários tipos de ramificações temporárias (no contexto do GitHub Flow, a ramificação master é permanente e as demais são temporárias). Filiais permanentes:

• mestre: ninguém deve tocar neste galho ou empurrar nada ali. Nessa estratégia, o master exibe a versão estável mais recente usada na produção (ou seja, no servidor real);
• desenvolvimento é o ramo do desenvolvimento. Poderia ser potencialmente instável.

O desenvolvimento é realizado por meio de três ramos temporários auxiliares :

1. Ramos de recursos - para desenvolver novas funcionalidades.
2. Liberar ramificações - para se preparar para o lançamento de uma nova versão do projeto.
3. As ramificações de hotfix são uma solução rápida para um defeito que já foi encontrado por usuários reais em um servidor real.

Ramos de recursos

Branches de recursos são criados por desenvolvedores para novas funcionalidades. Eles devem sempre ser baseados no ramo de desenvolvimento. Depois de concluir o trabalho na nova funcionalidade, você precisa criar uma solicitação pull no branch de desenvolvimento. É claro que em equipes grandes pode haver mais de uma feature branch por vez. Mais uma vez, preste atenção na imagem no início da descrição da estratégia GitFlow.

Liberar ramificações

Quando o número necessário de novos recursos tiver sido preparado na ramificação de desenvolvimento, você poderá se preparar para lançar uma nova versão do produto. O branch release nos ajudará com isso. que é criado com base no ramo de desenvolvimento. Ao trabalhar com o branch de lançamento, você precisa encontrar e corrigir todos os defeitos. Quaisquer novas alterações necessárias para estabilizar o branch de lançamento também devem ser mescladas novamente no desenvolvimento. Isso é feito para estabilizar e desenvolver o ramo. Quando os testadores dizem que o branch é estável o suficiente para uma nova versão, ele é mesclado no branch master. A seguir, uma tag é criada neste commit (tag: você pode ler mais sobre isso aqui ), à qual é atribuído um número de versão. Por exemplo, você pode olhar a imagem no início da estratégia. Então, aí Tag 1.0 é apenas um rótulo que indica a versão 1.0 do projeto. E a última coisa é um hotfix de branch.

Ramos de hotfix

As ramificações Hotfix também se destinam ao lançamento de uma nova versão no master. A única diferença é que este lançamento não está planejado. Há situações em que os defeitos chegam à liberação e já são descobertos na produção. Por exemplo, iOS: assim que eles lançam uma nova versão, você recebe imediatamente um monte de atualizações com correções para defeitos descobertos após o lançamento. Nesse sentido, é necessário corrigir rapidamente esse defeito e lançar uma nova versão. Na nossa foto isso corresponde à versão 1.0.1. A ideia é que o trabalho em novas funcionalidades não pare nos momentos em que for necessário consertar um defeito em um servidor real (como dizemos, “em produção”: novamente, uma cópia da palavra em inglês produção). O branch hotfix deve ser criado a partir do branch master, pois representa o estado que funciona em produção. Assim que a solução do defeito estiver pronta, ela é mesclada no master e um novo rótulo é criado. Assim como preparar uma ramificação de lançamento, uma ramificação de hotfix deve mesclar sua solução na ramificação de desenvolvimento.

A estratégia de fluxo de trabalho de bifurcação

Como parte da estratégia Forking Workflow, o desenvolvimento é realizado de forma que existam 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 em posse de outro desenvolvedor que deseja fazer alterações no original).

Parece um pouco estranho até agora, certo? Para aqueles que já encontraram o desenvolvimento de código aberto, esta abordagem já é familiar. Esta estratégia oferece a seguinte vantagem: o desenvolvimento pode ser realizado em um repositório fork sem conceder direitos de desenvolvimento conjunto no repositório original. Obviamente, o proprietário do repositório original tem o direito de rejeitar as alterações propostas. Ou concorde e mate-os. Isso é conveniente tanto para o proprietário do repositório original quanto para o desenvolvedor que deseja participar da criação de algum produto. Por exemplo, você pode propor alterações no kernel do Linux . Se Linus decidir que fazem sentido, as alterações serão adicionadas (!!!).

O exemplo de fluxo de trabalho de bifurcação

O Forking Flow é usado no GitHub quando há alguma biblioteca que você deseja usar. Possui um defeito que impede seu aproveitamento integral. Digamos que você se aprofundou o suficiente no problema e conhece a solução. Usando a estratégia The Forking Workflow, você pode resolver esse problema sem conceder direitos para trabalhar no repositório da biblioteca original. Para começar, você precisa selecionar um repositório, por exemplo, o núcleo do Spring Framework ... Encontre o botão Fork no canto superior direito e clique nele: isso levará algum tempo, após o qual uma cópia deste repositório original aparecerá em seu conta pessoal, o que indicará que se trata de um fork: Então você pode trabalhar com este repositório normalmente, adicionar alterações ao branch master e quando tudo estiver pronto, criar um Pull-Request para o repositório original. Para fazer isso, clique no botão Nova solicitação pull :

Qual estratégia escolher

Git é uma ferramenta flexível e poderosa que permite trabalhar usando uma ampla gama de processos e estratégias. Mas quanto maior for a escolha, mais difícil será decidir qual estratégia escolher agora. Claramente, não existe uma resposta única para todos. Tudo depende da situação. No entanto, existem algumas recomendações que podem ajudar com isso:

1. É melhor escolher primeiro a estratégia mais simples. 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ções de desenvolvedor.
3. Observe os prós e os contras das diferentes estratégias e, de acordo com o projeto, escolha a mais adequada.

Isso é tudo que eu queria contar sobre a estratégia de ramificação no git. Obrigado pela atenção :) Assine minha conta GitHub , costumo postar meu trabalho lá em diversas tecnologias e ferramentas que utilizo em meu trabalho

Links Úteis

• Fluxo do GitHub: a melhor maneira de usar Git e GitHub
• Solicitações pull no GitHub ou Como posso fazer alterações no projeto de outra pessoa
• GitHub: sobre solicitações pull
• Integração contínua, entrega e implantação diferenciadas
• Noções básicas do Git: trabalhando com tags
• Habr: modelo de ramificação bem-sucedido para Git