Explore o fluxo de trabalho de ramificação de recursos

Concluído

A ideia central por trás do fluxo de trabalho de ramificação de recursos é que todo o desenvolvimento de recursos deve ocorrer em uma ramificação dedicada em vez da ramificação principal.

O encapsulamento torna mais fácil para vários desenvolvedores trabalharem em um recurso específico sem perturbar a base de código principal. Isso também significa que a ramificação principal nunca conterá código quebrado, uma grande vantagem para ambientes de integração contínua.

O encapsulamento do desenvolvimento de funcionalidades também possibilita o uso de pull requests, que são uma maneira de iniciar discussões em torno de um ramo. Eles permitem que outros desenvolvedores saiam de um recurso antes que ele se integre ao projeto oficial. Ou, se ficares preso no meio de uma funcionalidade, podes abrir um pull request pedindo sugestões aos teus colegas.

Os pull requests tornam incrivelmente fácil para a vossa equipa comentar o trabalho uns dos outros. Além disso, as branches de funcionalidade podem (e devem) ser submetidas para o repositório central. Ele permite compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial.

Como o principal é o único ramo "especial", o armazenamento de várias ramificações de recursos no repositório central não representa nenhum problema. Também é uma maneira conveniente de fazer backup dos compromissos locais de todos.

Liberar fluxo de trabalho de filial

Além do fluxo de trabalho de ramificação de recurso, outra estratégia comumente usada em fluxos de trabalho de ramificação do Git é a estratégia de ramificação de versão. Esta estratégia envolve a criação de filiais dedicadas especificamente para a preparação de lançamentos. A ramificação de versão é normalmente criada a partir de uma ramificação de recurso estável, garantindo que ela contenha apenas código cuidadosamente testado e validado. Uma vez criada, a ramificação de lançamento passa por testes adicionais, correções de bugs e esforços de estabilização para preparar a base de código para implantação. A ramificação de lançamento permite o isolamento de atividades relacionadas à versão do desenvolvimento contínuo de recursos, fornecendo um ambiente controlado para finalizar e polir a próxima versão. Depois de todos os ajustes e verificações necessários terem sido feitos na ramificação de lançamento, ela é então fundida na ramificação principal ou implantada diretamente na produção, dependendo do processo de lançamento da equipa. A Estratégia de Ramificação de Lançamento ajuda as equipes a gerenciar as complexidades da coordenação das atividades de lançamento, mantendo uma ramificação principal estável para desenvolvimento contínuo.

Fluxo de trabalho de desenvolvimento baseado em tronco

O fluxo de trabalho de desenvolvimento baseado em tronco assume um repositório central, e o principal representa o histórico oficial do projeto. Em vez de se comprometer diretamente com sua ramificação principal local, os desenvolvedores criam uma nova ramificação sempre que começam a trabalhar em um novo recurso. As ramificações de recursos devem ter nomes descritivos, como new-banner-images ou bug-91. A ideia é dar a cada ramo um propósito claro e altamente focado.

O Git não faz distinção técnica entre as ramificações principal e de recurso, para que os desenvolvedores possam editar, preparar e confirmar alterações em uma ramificação de recurso.

Criar uma ramificação

Quando se está a trabalhar num projeto, há sempre várias funcionalidades ou ideias em andamento – algumas das quais estão prontas para serem implementadas e outras que ainda não estão. A ramificação existe para ajudá-lo a gerenciar esse fluxo de trabalho. Quando você cria uma ramificação em seu projeto, você cria um ambiente onde você pode experimentar novas ideias.

Além de criar ramificações para novos recursos ou correções, as equipes que seguem um fluxo de trabalho de ramificação de liberação também criam ramificações dedicadas especificamente para preparar versões. Essas ramificações de lançamento são normalmente derivadas de ramificações estáveis de funcionalidades para garantir que contenham código cuidadosamente testado e validado. Uma vez criada, a ramificação de lançamento passa por testes adicionais, correções de bugs e esforços de estabilização para preparar a base de código para implantação.

Adicionar confirmações

Uma vez que sua filial tenha sido criada, é hora de fazer alterações. Sempre que você adiciona, edita ou exclui um arquivo, você faz uma confirmação e adiciona-os à sua ramificação.

Adicionar commits acompanha o teu progresso enquanto trabalhas numa branch de funcionalidades.

Os compromissos também criam um histórico transparente do seu trabalho que outras pessoas podem seguir para entender suas ações e por quê.

Cada confirmação tem uma mensagem de confirmação associada explicando por que uma determinada alteração foi feita.

Além disso, cada compromisso é considerado uma unidade separada de mudança. Ele permite que você reverta as alterações se um bug for encontrado ou você decidir ir em uma direção diferente.

As mensagens de confirmação são essenciais, especialmente porque o Git rastreia suas alterações e as exibe como confirmações uma vez enviadas para o servidor.

Ao escrever mensagens de confirmação claras, você pode facilitar o acompanhamento e o feedback de outras pessoas.

Abrir um pedido de integração (pull request)

Os Pull Requests iniciam uma discussão sobre os teus commits. Como eles estão totalmente integrados ao repositório Git subjacente, qualquer pessoa pode ver exatamente quais alterações seriam mescladas se aceitassem sua solicitação.

Você pode abrir uma solicitação pull a qualquer momento durante o processo de desenvolvimento quando:

• Você tem pouco ou nenhum código, mas quer compartilhar capturas de tela ou ideias gerais.
• Você está preso e precisa de ajuda ou conselhos.
• Você está pronto para que alguém analise seu trabalho.

Usando o Sistema @mention na sua mensagem de pull request, pode pedir feedback de pessoas ou equipas específicas, estejam elas no corredor ou a 10 fusos horários.

As solicitações pull ajudam a contribuir para projetos e para gerenciar alterações em repositórios compartilhados.

Se você estiver usando um modelo Fork & Pull, as solicitações pull fornecem uma maneira de notificar os mantenedores do projeto sobre as alterações que você gostaria que eles considerassem.

Se você estiver usando um Modelo de Repositório Compartilhado, as Solicitações Pull ajudarão a iniciar a revisão de código e a conversa sobre as alterações propostas antes que elas sejam mescladas na ramificação principal.

Discuta e reveja o seu código

Assim que um Pull Request for aberto, a pessoa ou a equipa que revê as suas alterações pode ter perguntas ou comentários.

Talvez o estilo de codificação não corresponda às diretrizes do projeto, a alteração não tem testes unitários, tudo parece excelente e os parâmetros estão em ordem.

As solicitações pull são projetadas para incentivar e capturar esse tipo de conversa.

Você também pode continuar a empurrar para o seu ramo, considerando a discussão e o feedback sobre seus compromissos.

Suponha que alguém comente que você esqueceu de fazer algo, ou se houver um bug no código, você pode corrigi-lo em sua ramificação e impulsionar a mudança.

O Git mostrará seus novos commits e qualquer feedback que você possa receber na visualização unificada Pull Request.

Os comentários Pull Request são escritos em Markdown, para que você possa incorporar imagens e emojis, usar blocos de texto pré-formatados e outras formatações leves.

Implantar

Com o Git, você pode implantar a partir de uma ramificação para teste final em um ambiente antes de mesclar com a principal.

Depois que sua solicitação pull tiver sido revisada e a ramificação passar nos testes, você poderá implantar suas alterações para verificá-las. Você pode revertê-lo se sua ramificação causar problemas implantando a rede principal existente.

Mesclar

Depois que as alterações forem verificadas, é hora de mesclar seu código na ramificação principal.

Uma vez mesclados, os Pull Requests preservam um registro das alterações históricas no seu código. Por serem pesquisáveis, eles permitem que qualquer pessoa volte no tempo para entender por que e como uma decisão foi tomada.

Você pode associar problemas ao código incorporando palavras-chave específicas ao texto do Pull Request. Quando o seu Pull Request é integrado, as questões relacionadas também podem ser fechadas.

Esse fluxo de trabalho ajuda a organizar e rastrear filiais focadas em conjuntos de recursos de domínio de negócios.

Outros fluxos de trabalho do Git, como o Git Forking Workflow e o Gitflow Workflow, são focados no repositório e podem usar o Git Feature Branch Workflow para gerenciar seus modelos de ramificação.