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 desenvolvimento de recursos de encapsulamento também possibilita o uso de solicitações pull, que são uma maneira de iniciar discussões em torno de uma ramificação. Eles permitem que outros desenvolvedores saiam de um recurso antes que ele se integre ao projeto oficial. Ou, se você ficar preso no meio de um recurso, você pode abrir uma solicitação pull pedindo sugestões de seus colegas.

As solicitações pull tornam incrivelmente fácil para sua equipe comentar o trabalho uns dos outros. Além disso, as ramificações de recursos podem (e devem) ser enviadas 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 mesclada na ramificação principal ou implantada diretamente na produção, dependendo do processo de liberação da equipe. 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 um ramo

Quando você está trabalhando em um projeto, você terá muitos recursos ou ideias diferentes em andamento a qualquer momento – alguns dos quais estão prontos para ir e outros nã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 liberação são normalmente derivadas de ramificações de recursos estáveis 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 confirmações acompanha seu progresso enquanto você trabalha em uma ramificação de recurso.

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 Pull

Os Pull Requests iniciam uma discussão sobre seus compromissos. 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 @mention sistema em sua mensagem Pull Request, você pode pedir feedback de pessoas ou equipes específicas, estejam elas no corredor ou a 10 fusos horários de distância.

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

Depois que uma solicitação pull for aberta, a pessoa ou equipe que revisa suas alterações pode ter perguntas ou comentários.

Talvez o estilo de codificação não corresponda às diretrizes do projeto, a mudança está faltando testes de unidade, tudo parece excelente e os adereços 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.

Implementar

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.

Unir

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 é mesclado, os problemas relacionados também podem ser fechados.

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.